| name | code-review |
| description | Structured code review for PRs, diffs, or changed files. Use when: (1) reviewing a pull request, (2) checking code quality before merge, (3) auditing changes for correctness/security/performance, (4) user asks to review code or a diff. NOT for: debugging failures (use debug), running tests (use verify), or general code reading. |
| when_to_use | Use when the user asks to review code, a PR, or a diff. Also use proactively after implementing significant changes. |
| user-invocable | true |
| disable-model-invocation | false |
Code Review
Systematic review that catches real issues, not style noise.
Goal
Evaluate changed code for correctness, security, performance, and maintainability. Produce actionable findings ranked by severity.
Workflow
- Gather the diff. Use
git_diff, gh pr view, or read the changed files directly.
- Understand intent. Read PR description, commit messages (
git_log), or ask the user what the change is supposed to do.
- Review against checklist (below). Skip categories that don't apply.
- Report findings grouped by severity: critical → warning → suggestion.
Review Checklist
Correctness
- Does the code do what the description/commit says?
- Edge cases: nil/empty inputs, boundary values, concurrent access
- Error handling: are errors checked, propagated, and not swallowed?
- State management: are resources cleaned up (defer, close, cancel)?
Security
- Input validation: is user input sanitized before use?
- Secrets: no hardcoded keys, tokens, or passwords
- Injection: SQL, command, path traversal, XSS
- Auth: are access checks in place where needed?
Performance
- Unnecessary allocations in hot paths
- N+1 queries or unbounded loops
- Missing pagination or limits on user-controlled sizes
- Locks held too long or missing where needed
Design
- Does the change fit the existing architecture?
- Are new abstractions justified or overengineered?
- Duplication: could existing helpers be reused?
- API surface: are new exports intentional and well-named?
Tests
- Are the changes covered by new or existing tests?
- Do tests verify behavior, not implementation details?
- Are edge cases and error paths tested?
Output Format
## Review: [brief title]
### Critical
- [file:line] Issue description. Why it matters. Suggested fix.
### Warnings
- [file:line] Issue description.
### Suggestions
- [file:line] Optional improvement.
### Summary
N critical, N warnings, N suggestions. [Overall assessment: approve / request changes / needs discussion]
Guardrails
- Focus on logic and behavior, not formatting or style preferences.
- If unsure about intent, state the assumption and flag for discussion.
- Don't nitpick: every comment should justify its attention cost.
- Verify findings before reporting — re-read the code to confirm.
