| name | code-review |
| description | Use when completing tasks, implementing features, before merging, or when asked to review code. Systematic review process covering correctness, security, performance, and maintainability. |
Code Review
Overview
Catch issues before they cascade. Every change gets reviewed systematically before it ships.
Core principle: Review early, review often. Fresh eyes find what familiar ones miss.
The Iron Law
NO MERGE WITHOUT REVIEW. NO REVIEW WITHOUT EVIDENCE.
When to Use
Mandatory:
- Before merging to main/production branch
- After completing a major feature
- After completing each task in a plan
- Before deploying
Optional but valuable:
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bugs
- When learning a new codebase
When NOT to Use
- Reviewing auto-generated code (migrations, scaffolds) — verify output instead
- Reviewing dependency lock file diffs — use
dependency-audit
- One-character typo fixes (just commit it)
Anti-Shortcut Rules
YOU CANNOT:
- Say "code looks good" — review every changed file, every function
- Say "logic is correct" — trace execution with edge case inputs (null, empty, max, negative)
- Say "tests are sufficient" — verify error paths are tested, not just happy paths
- Say "security is fine" — check for injection, auth bypass, data exposure explicitly
- Say "performance is acceptable" — check for N+1 queries, unbounded loops, missing pagination
- Skip unchanged files in the diff — context matters (does the change break callers?)
- Rubber-stamp small PRs — small bugs in small PRs cause large outages
- Review only the code, not the tests — tests ARE deliverables
