| name | code-review |
| description | Comprehensive code review. Reviews staged/unstaged changes for correctness, simplicity, and test coverage. Use when the user says 'review', 'code review', or 'check my work'. |
| user-invocable | true |
| argument-hint | [branch or file path] |
Code Review
You are performing a comprehensive code review.
Step 0: Gather the diff
Determine what to review:
- If
$ARGUMENTS is a branch name or PR number, get that diff
- If
$ARGUMENTS is a file path, review that file's unstaged changes
- If no arguments, review all staged + unstaged changes:
git diff and git diff --cached
- Run
git status (never use -uall) to see untracked files
Collect the full list of changed files.
If no backlog ticket is linked, create a temporary AC list from the user's original request.
Step 1: Spawn code_reviewer subagent (MANDATORY)
Launch the code_reviewer subagent with the diff. It owns:
- Independent verification
- AC-to-evidence mapping
- Running
pnpm test, pnpm run build, pnpm run lint
If visual changes exist (CSS, components, layouts), also launch ux_designer with screenshots.
Step 2: Correctness & bugs
Review for:
- Logic errors, off-by-one, null/undefined access
- Missing error handling at system boundaries (user input, fetch calls, localStorage)
- Broken imports, missing dependencies
- Build issues
Step 3: Overcomplexity check
This is critical. Review for:
- Premature abstraction: Helper/utility created for one-time use?
- Over-engineering: Feature flags, config objects, factory patterns without justification?
- Unnecessary indirection: Simple component split into 5 files?
- Gold-plating: Docstrings, comments, type annotations added to unchanged code?
- Backwards-compat hacks: Renamed
_unused vars, re-exported types?
For each issue, suggest the simpler alternative.
Step 4: AC-to-Evidence Matrix (MANDATORY)
Every review includes:
- One row per acceptance criterion
- Evidence: automated test, manual verification, or command output
- Status: Verified / Partial / Missing
Rules:
- Missing evidence for any AC is a Must fix.
- Behavior AC without test and no justification is a Should fix.
Step 5: Ticket hygiene (MANDATORY when ticket exists)
- Every completed AC is checked off in the ticket file
- AC IDs use
AC-01 format
- Verification evidence table has entries for completed ACs
- Deviations from spec are documented in Implementation Notes
- If fully complete:
status: done and completed_at set
Step 6: Summary
Review Summary
Files reviewed: (list)
Verdict: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION
Findings by severity:
- Must fix — Bugs, build breakers, security issues, missing AC evidence
- Should fix — Overcomplexity, missing tests, stale ticket
- Consider — Style nits, minor improvements
AC Evidence Matrix
End with what's good about the changes.
