Review

---
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

1. Identify what to review:
   - If a PR number is given: `gh pr diff <number>`
   - Otherwise: `git diff` for unstaged, `git diff --staged` for staged
2. Read each changed file fully for context
3. 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
4. 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