Immutable. This exact content is served forever at /api/v1/blob/664557b4579a27e2.
--- name: review description: > Perform a structured code review on a diff, PR, or set of changes. USE WHEN reviewing code, reviewing PRs, checking diffs, or asked to find issues in changes. --- # Code Review Systematically review changes for correctness, security, and maintainability. ## Steps 1. Read the full diff. Understand the scope before commenting. 2. Check PR description or commit messages for context — what problem is being solved? 3. Review in priority order: - **Correctness** — Logic errors, off-by-one bugs, missing edge cases, race conditions. - **Security** — Injection risks, hardcoded secrets, missing validation, exposed PII. - **Error handling** — Unhandled failures, swallowed exceptions, missing error paths. - **Architecture** — Does this follow existing patterns? Are boundaries respected? - **Testing** — Are new behaviors tested? Are error paths covered? - **Naming & clarity** — Would a new team member understand this? 4. For each issue: - Point to the exact file and line. - Explain *why* it's a problem, not just *what* to change. - Suggest a fix when possible. - Mark as **blocking** (must fix) or **suggestion** (nice to have). 5. If the code is solid, say so. Don't manufacture criticism. ## Output Format ``` ## Summary [1-2 sentence overview] ## Issues - **[blocking]** file.ts:42 — [problem and suggested fix] - **[suggestion]** file.ts:15 — [observation and reasoning] ## Verdict [Approve / Request changes / Needs discussion] ``` ## Gotchas - Don't nitpick style if a formatter/linter handles it. - Don't rewrite the author's approach — review what's there, not what you'd have written. - Don't approve with unresolved blocking issues just to be polite. - Check the full PR, not just the latest commit — bugs often hide in earlier commits.