/build
Build a feature using the adversarial review loop. Runs builder agents, then critic, then fixes, then critic again — repeating until critic passes and tests are green.
Orchestrator
Resolve Input — Find the Plan
Before any agent runs, /build detects the entry point type and resolves a task ID for tracking throughout the pipeline.
commands/build.md
- @plans/filename.md — Read the file. Scan for ## Backlog Task: TASK-XX. Extract the task ID. - TASK-XX — Load the full task context via backlog task <id> --plain. - @backlog/tasks/task-N - Title.md — Read the file. Extract the task ID from the id: field. - Inline text — Create a task on the fly.
Any input format normalizes to a task ID + implementation plan. Inline text auto-creates a backlog task. Plan files without task links get a task created and bidirectionally linked.
Explorer
Haiku
+
Architect
Opus
Prepare — Explorer & Architect
Explorer maps the codebase, architect produces the design plan, and researcher validates technical decisions if needed.
commands/build.md
1. Invoke explorer to map all affected files ... 3. If design decisions exist, invoke architect and wait for the design plan 5. Architect may have already dispatched researcher internally for technical validation. If additional library or API research is still needed, invoke researcher explicitly. 6. Present the plan to the human before proceeding (one paragraph summary)
The orchestrator presents a one-paragraph summary to the human before any code is written — a checkpoint to catch misunderstandings early. The architect may internally dispatch a researcher for technical validation, but if more research is needed, the orchestrator invokes one explicitly.
commands/build.md
Never set run_in_background: true on any Agent tool call in this pipeline. // Stalls are caught immediately, agent output // flows to the next agent's context, and the // human can see progress in real time.
Background execution is banned across the entire /build pipeline. If an agent stalls for more than 10 minutes, the orchestrator cancels and retries with a skeleton-first, section-by-section approach.
Storage
Sonnet
+
Frontend / Backend
Sonnet
Build — Run the Builders
Storage runs first if schema changes are needed, then builder agents execute with skills directives from the plan.
commands/build.md
If schema or storage changes are needed, invoke storage FIRST and wait for completion. If the plan contains a **Skills:** directive, extract the listed skills and include them in the builder agent's instructions with this directive: "Before starting work, invoke each skill listed under **Skills:** using the Skill tool."
Storage always runs before builders to ensure schema changes are in place. Skills directives propagate from the plan file through the orchestrator into each builder's instructions — the builder doesn't need to know about the plan, just the skills it must load.
commands/build.md
When invoking frontend for any UI/HTML/visual deliverable, your instructions MUST include: - The design quality bar: distinctive, production- grade, not generic AI aesthetics - Explicit instruction: "Apply your preloaded frontend-design principles — commit to a bold aesthetic direction before writing code."
The frontend agent has the frontend-design skill preloaded. The orchestrator's instructions reinforce the quality bar — distinctive output is a requirement, not a suggestion.
Critic
Opus
⇆
Builder
Sonnet
Adversarial Loop — Critic vs Builder
The critic evaluates all new and changed code. If it finds issues, a builder fixes them. This repeats until the critic passes or the iteration limit is reached.
commands/build.md
Invoke critic with exactly this context: - Iteration 1: the list of new/changed files for the critic to read - Iteration 2+: the raw git diff HEAD output only — do NOT pass a file list; the critic must work from the diff alone
On subsequent iterations, the critic only sees the diff — not the full codebase. This forces it to evaluate whether the fix actually resolved the issue, rather than re-reviewing everything from scratch.
commands/build.md
If critic returns FAIL: a. Pass the specific ISSUE list to the relevant builder agent b. Builder fixes ONLY the flagged items — no other changes c. Run git diff HEAD and pass that output to the next critic invocation
Builders fix only what the critic flagged — no scope creep. The diff from the fix becomes the critic's input for the next iteration.
commands/build.md
If still failing after the max adversarial loop iterations (default 3): STOP. Set task to Blocked. Report to human with the remaining issues. Do not continue looping. The problem is likely a design issue, not an implementation issue.
Three iterations is the hard limit. If the critic still fails after three rounds, the orchestrator stops and sets the task to Blocked. The reasoning: repeated failures usually indicate a design flaw that more code can't fix.
Tester
Sonnet
Verify — Run the Tests
The tester runs the full test suite. If tests fail, the failures are passed back to a builder agent, and the adversarial loop restarts from Phase 3. Tests must be green before the pipeline can proceed.
commands/build.md
16. Invoke tester to run the full test suite ... 18. If tests fail: pass failures to builder, then return to step 12 (critic loop) 19. If tests pass: proceed to Phase 5
Test failures don't just retry the tests — they send the builder back through the full adversarial critic loop. This ensures the fix itself gets adversarial review, not just a re-run of the test suite.
Reviewer
Sonnet
+
Author
Haiku
Wrap up — Reviewer & Author
Reviewer performs a final standards pass, returning structured BLOCKER / WARNING / SUGGESTION findings. BLOCKERs must be resolved. Then Author updates README, docstrings, and CHANGELOG after reviewer sign-off.
commands/build.md
20. Invoke reviewer for a final standards pass 21. After reviewer: append notes, then push 22. Invoke author to update docs and CHANGELOG 23. After author: append notes, then push
Author only runs after reviewer sign-off — never before. BLOCKERs from the reviewer must be resolved first. WARNINGs are surfaced in the final report but do not block the pipeline.
Orchestrator
Report — Delivery Summary
The final report is delivered to the human with a complete summary of the build.
commands/build.md
Report to human: - What was built - How many adversarial loop iterations it took - Any WARNINGs from reviewer that were not fixed (with reasoning) - Test pass/fail summary
The task is set to "Ready for Review" — never automatically to Done. Only a human moves a task to Done.