| name | review |
| description | Use after a feature or substantial change is built, before committing or moving on — when code was just generated and skimming it risks shipping a bug, a plan deviation, or an architecture-boundary violation you won't notice for days. |
review
Overview
Generated code looks done long before it is done. review checks the finished feature against the plan and the architecture, then reports issues by severity. It never auto-fixes — you stay in control of every change.
When to use
- A feature is "finished" (especially 100+ lines, or anything with logic).
- Before you commit or move to the next feature.
- After a session where the agent built a lot, fast.
Skip for: trivial edits with no logic.
Process
- Plan conformance. Did the implementation do what the
architect plan said? List deviations.
- Architecture boundaries. Does it respect the rules in the architecture context file (e.g. API routes hold no UI logic, components hold no DB logic, layers don't reach across)? Flag every violation.
- Production readiness. Error handling, edge cases, input validation at trust boundaries, no secrets, no dead code, no stray TODOs.
- Report by severity:
- Critical — bugs, security, data loss, broken boundaries. Must fix.
- Important — missing handling, plan deviation, real risk. Should fix.
- Minor — naming, polish, nits. Optional.
- Do not auto-fix. Present the list; the human decides what to fix and when.
Common mistakes
- Fixing as you find → you lose the audit trail and the human loses control. Report only.
- One flat list → severity grouping is the whole point.
- Reviewing against vibes → review against the plan and the architecture file, not gut feel.
