| name | review-pr |
| description | Review a pull request (a diff or set of changed files) for correctness bugs and write findings to review.md. Use whenever asked to review a PR, a diff, or changed code. |
review-pr
Encodes the Reviewer's process so it's the same every time, not re-explained each PR.
Steps
- Locate the change. Identify the diff (
PR.diff, a branch, or named changed files). If it's ambiguous which change is "the PR", ask once — don't guess across multiple candidates.
- Read for intent, not just the lines. For each changed hunk, open the full function it lives in. A changed line is correct only relative to its callers, invariants, and edge cases.
- Hunt correctness first. In priority order: inverted boolean logic (
and/or, flipped comparisons), off-by-one, null/empty/zero handling, broken invariants, wrong operator, unhandled error path. These page people; find them first.
- Prove each finding. Quote the exact line, give
file:line, and state one concrete input for which it does the wrong thing. No vague "might be an issue".
- Separate the secondary. After correctness, a short "minor" section (clarity, naming, missing tests). Never let nits bury a real bug.
- Write
review.md in the repo root. Structure (placeholders — fill from the actual code, don't copy this):
## Correctness
- <file>:<line> — <one line: what's wrong>; for <concrete input> it does
<the wrong thing>. Should be <the fix>.
## Minor
- <clarity / naming / missing-test notes, if any>
## Checked, looks fine
- <what you verified that was OK>
- If you find no correctness bug, say so and list what you checked. Do not invent issues.
Definition of done
review.md is non-empty and every correctness finding has a file:line + a failure case. A Stop hook enforces non-emptiness.