/review
Run the adversarial critic against existing code without rebuilding. Use when you want to harden code that already exists, or run a quality pass on a completed feature before shipping.
Explorer
Haiku
Resolve Task — Silent Lookup
Silently attempt to find a linked backlog task from the input. Unlike /build, this step never interrupts the user.
commands/review.md
This step is silent — never interrupt or message the user about it. If no task ID is found: set task_id to empty and proceed without tracking. No message to user. - @plans/filename.md — Scan for ## Backlog Task: TASK-XX - TASK-XX — Use the ID directly - Inline free-text — No task; set task_id to empty
The most important behavioral difference from /build: task resolution is completely silent. /build creates tasks on-the-fly for inline text and messages the user about tracking. /review never interrupts — it proceeds without tracking if no task is found.
Critic
Opus
+
Builder
Sonnet
Review — Critic Loop & Tests
Explorer maps the relevant files, then the critic loop begins. The critic evaluates, and if it finds issues, a builder fixes them — repeating until PASS or 3 iterations.
commands/review.md
Invoke critic with exactly this context: - Iteration 1: pass the list of new/changed files for the critic to read - Iteration 2+: pass only the raw git diff HEAD output — do NOT re-pass the file list; the critic works from the diff alone
Same iteration pattern as /build's adversarial loop — file list on first pass, diff-only thereafter. The difference: /review is inspection-focused, not build-focused. It hardens existing code rather than building new features.
commands/review.md
## Rules - Never change task status — review is an inspection tool only; status changes are owned by /build - Never interrupt or ask about tasks if none found — proceed silently without tracking - Push after every single backlog operation - Use backlog CLI via Bash — do NOT use MCP tools
These are the key behavioral constraints that distinguish /review from /build. Review never moves a task's status — it only appends notes. It never interrupts the user about missing tasks. Status lifecycle is exclusively owned by /build.
commands/review.md
On PASS: invoke tester to verify nothing broke
Report: iteration count, issues found, issues
resolved, test result
On PASS, the tester runs to verify that the critic's approved state hasn't broken any existing tests. The final report gives a complete picture: how many iterations, what was found, what was fixed, and whether tests pass.