| name | code-review |
| description | Review code changes for correctness, regressions, security risks, and missing tests. Use whenever the user asks for a review or before merging non-trivial work. |
Code Review
Treat review as bug-finding, not prose generation.
Priorities
Check these first:
- Correctness and behavior regressions
- Security and permission mistakes
- Data loss, migration, and state corruption risks
- Missing or weak test coverage
- Performance issues that are obvious from the diff
Review Workflow
- Read the requirements or task description first.
- Inspect the diff and the touched files, not just the final code.
- Compare implementation against nearby patterns in the codebase.
- Verify tests cover the changed behavior and likely edge cases.
- Flag only concrete issues you can defend from the code.
Response Format
Always lead with findings. Keep them ordered by severity.
1. High: [short title] — [why it is wrong]
File: /absolute/path/to/file.ts:123
2. Medium: [short title] — [risk or missing case]
File: /absolute/path/to/file.ts:45
Open questions:
- [only if intent is unclear]
Rules:
- Cite exact file paths and lines when possible.
- Explain the failure mode, not just the smell.
- Suggest the smallest credible fix.
- If there are no findings, say so explicitly and mention residual test gaps.
Things Worth Flagging
- Wrong conditionals, off-by-one logic, stale assumptions
- Missing auth, permission, or ownership checks
- New APIs without tests
- Path handling that can escape an expected root
- Silent error swallowing on external I/O
- Schema changes without migration or compatibility handling
- Concurrency issues, duplicate side effects, non-idempotent retries
