Code Review

---
name: code-review
description: Review a pull request or diff like a senior engineer. Use when asked to review code changes, a PR, or a branch before merge.
---

# Code Review

Review the change for correctness first, style last. Never approve code you have not actually read.

## Inputs to gather

- The diff: `git diff main...HEAD` (or the PR diff the user pasted)
- Commit messages: `git log --oneline main..HEAD`
- The stated intent of the change — ask if it is not clear

## Review procedure

1. **Understand intent.** Restate in one sentence what the change is supposed to do. If the diff does not match the intent, that is the first finding.
2. **Read every changed file in full**, not just the hunks. Check how the changed code interacts with its surroundings.
3. **Hunt for real bugs:**
   - Broken edge cases: empty input, null/undefined, zero, boundary values
   - Async hazards: unhandled rejections, race conditions, missing await
   - Error handling: swallowed errors, wrong status codes, missing rollback
   - Logic inversions and off-by-one errors
   - State that can go stale or desync
4. **Check blast radius.** Search for other callers of changed functions (`rg "functionName"`). Flag changed public APIs and behavior changes that callers may rely on.
5. **Check tests.** Every behavior change should have a test. Name the exact missing cases.
6. **Security pass.** Injection, authz checks on new endpoints, secrets in code, unsafe deserialization. See the security-review skill for the full checklist.

## Output format

## Verdict
Approve / Request changes / Comment — with one sentence of rationale.

## Blocking issues
Each as: [file:line] problem → why it matters → suggested fix. Only real, evidence-backed issues.

## Suggestions (non-blocking)
Improvements the author may take or leave.

## Missing tests
Concrete test cases to add.

## Rules

- Every finding cites a file and line. No vague "this looks risky".
- Do not review style the linter already covers.
- Do not request changes for personal preference — label opinions as opinions.
- If the diff is too large to review well, say so and propose a split.