code-review

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)

1. Every completed AC is checked off in the ticket file
2. AC IDs use AC-01 format
3. Verification evidence table has entries for completed ACs
4. Deviations from spec are documented in Implementation Notes
5. 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.