review-pr

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

1. 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.
2. 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.
3. 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.
4. 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".
5. Separate the secondary. After correctness, a short "minor" section (clarity, naming, missing tests). Never let nits bury a real bug.
6. 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>
   

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