| name | review |
| description | Review code changes for quality, security, and correctness |
/review — Code Review
When to use
When the user runs /review or asks to review changes/PR.
Steps
- Identify what to review:
- If a PR number is given:
gh pr diff <number>
- Otherwise:
git diff for unstaged, git diff --staged for staged
- Read each changed file fully for context
- Check for:
- Security: injection, XSS, hardcoded secrets, OWASP top 10
- Correctness: edge cases, off-by-one, null handling, race conditions
- Quality: naming, complexity, duplication, dead code
- Performance: N+1 queries, unnecessary allocations, missing indexes
- Tests: adequate coverage, meaningful assertions
- Report findings grouped by severity:
- CRITICAL: security issues, data loss risks
- WARNING: bugs, correctness issues
- SUGGESTION: style, refactoring opportunities
Rules
- Be specific: reference file:line
- Suggest fixes, don't just point out problems
- Acknowledge what's done well
- Don't nitpick formatting if a linter is configured