Use after completing implementation work, before merging or marking stories complete
Dispatch a code review subagent to catch issues before they cascade.
| Rationalization | Why It's Wrong | What To Do Instead |
|---|---|---|
| "This change is too simple to review" | Simple changes break complex systems. Reviews catch what you missed. | Request the review. Simple changes review fast. |
| "I already reviewed my own code" | Self-review is biased. You see what you intended, not what you wrote. | Self-review is step 1. External review is step 2. |
| "Reviews slow down delivery" | Bugs in production slow down delivery more. Reviews catch bugs early. | Invest 10 minutes now to save hours of debugging. |
| "I'll review at the end" | Issues compound. Late review means late rework. | Review after each story, not after all stories. |
Mandatory:
Recommended:
Determine what code to review:
Code review happens in two stages. Order matters — do not skip or reorder.
Stage 1: Spec Compliance
dispatch-subagents/spec-reviewer-prompt.md templateStage 2: Code Quality (only after spec compliance passes)
dispatch-subagents/code-quality-reviewer-prompt.md template| Severity | Action |
|---|---|
| Critical | Fix immediately before proceeding |
| Important | Fix before marking story complete |
| Minor | Note for follow-up, OK to proceed |
After fixing reviewer issues: