Daniel Avila
7f890b1b3b
* feat: add Loops component type with referenced components Introduce "loops" as a new first-class component type — autonomous agentic workflows (goal + interval + stop condition) inspired by Loop Engineering and the Forward Future Loop Library. A loop references other components (agents, skills, hooks, commands) and the dashboard renders those references as clickable cards on the loop detail page. - Add 10 starter loops under cli-tool/components/loops/ (engineering, evaluation, operations) - Catalog generator: scan loops + write per-component content files - Dashboard: new type in icons/types/data, /loops page, and a "Referenced Components" section on the loop detail page - CLI: --loop flag installs the loop to .claude/loops/ and auto-installs its referenced components - Docs: CLAUDE.md and cli-tool rule updated Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T9ynMiCHt8JwdMd8KjCkES * feat: add 8 more loops (goal/loop/schedule patterns) Expand the loops catalog to 18, drawing ideas from community "Loop Engineering" patterns. Adds loops across the three trigger verbs (/goal, /loop, /schedule) and emphasizes the verifier-in-the-loop and budget / anti-spin guardrails: - engineering/five-minute-maintainer-loop - engineering/build-test-fix-loop - engineering/anti-spin-build-loop - engineering/completion-contract-loop (goal) - engineering/goal-refiner-loop (goal) - engineering/adversarial-review-loop (cross-model) - operations/overnight-pr-routine-loop (schedule) - evaluation/human-approval-loop (human-in-the-loop) All referenced components verified to exist; catalog regenerated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T9ynMiCHt8JwdMd8KjCkES --------- Co-authored-by: Claude <noreply@anthropic.com>
2.6 KiB
name, description, category, interval, stop-condition, components, tags
| name | description | category | interval | stop-condition | components | tags | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| adversarial-review-loop | Has a second, independent model review every change before merge so two different reviewers must agree — code only lands when both clear the bar. | engineering | 15m | The implementing agent and the independent cross-model reviewer both approve with no blocking findings and tests pass. |
|
|
Adversarial-Review Loop
Loop Engineering — the verifier inside the loop is the hard part, and an agent grading its own homework will delete the failing test and call it done. This loop puts a second, different model in the reviewer seat: two model families must agree before code lands.
🎯 Goal
Implement a change, then have an independent cross-model reviewer argue against it. Iterate on findings until both the builder and the outside reviewer sign off — no self-grading.
⏱️ Schedule
Suggested interval: 15m (or run until the change is merge-ready).
▶️ Run it
/loop 15m "Implement the change. Then have a different model review it adversarially for correctness, security and design. Address every blocking finding and re-run tests. Land it only when both the builder and the independent reviewer agree there are no blocking findings. Max 5 review rounds."
🔁 Iteration steps
- Build — implement the next slice.
- Cross-review — run
/gemini-reviewso a different model family critiques the diff. - Reason — collect blocking findings from the outside reviewer.
- Act — fix them;
architect-reviewvalidates the revision; re-run tests. - Observe — re-review with
/pr-review; loop until both sides agree (cap the rounds).
🛑 Stopping condition
Both reviewers report zero blocking findings and tests pass — or the review-round cap is reached and the loop hands off with the open findings.
💰 Budget & guardrails
A --max-iter style cap on review rounds and a severity threshold: only findings at/above the bar block. Two independent models must agree, so neither can rubber-stamp itself.
🧩 Referenced components
agent:expert-advisors/architect-review— the in-house reviewer.command:git-workflow/gemini-review— an independent, different-model review.command:git-workflow/pr-review— structured re-review checklist.
💡 Example
The builder ships an auth change; the cross-model reviewer flags a timing-attack risk the in-house reviewer missed. The loop fixes it, both agree, and only then does it land.