review-change
Installation
SKILL.md
Review a change
A review is a set of findings a second reader can act on without the reviewer in the room, and a decision. Everything else is noise.
The rules
| Id | Rule | In practice |
|---|---|---|
| REVIEW-1 | Findings on the introducing change, at the head sha | Open the change's head sha; every file:line is at that sha, or reads "from the inline diff" when there is none. A defect that predates the change goes to its own item, not this review. Essential findings only. |
| REVIEW-2 | One finding per thread, in Conventional Comments | Label, defect, file:line, consequence, rule broken, required behaviour, at most one suggestion. No hedges. Format in references/finding-format.md. |
| REVIEW-3 | The summary carries the decision | Two to four lines. The last one is the decision: approve, request changes, or needs a decider, with the open point and who decides. |
| REVIEW-4 | Mutate before trusting a test | Judge a test against the code it exercises, not its name. Invert one condition the change adds, run the suite, restore the file. A mutant that survives is a finding naming the missing case. A mutant that changed nothing proves nothing. Report mutants and catches as a count. Procedure in references/mutation-check.md. |
| REVIEW-5 | Review rounds fix only real defects | Cosmetic bot suggestions get a one-line verdict and no push. On your own change, answer every bot thread (fixed, or refuted with evidence) and resolve it. On someone else's change, reply and leave resolution to the author. |
| REVIEW-6 | Confirm the diff is absent before merging | Before reporting on, merging or closing a change, confirm its diff is not already on the target. Check a stacked change against its parent's tip. Re-diff a conflict resolution against the target's current file. |
| REVIEW-7 | Adversarial self-review before showing | Which claim rests on something not opened this session. Which number was recalled rather than computed. Which action does damage if the premise is wrong. Fix what it finds before any push, merge or live change. |
| REVIEW-8 | Sort proposals by what ships | Internals-only, or changes the released artifact (versioning, signing, distribution). The second needs a strong reason, stated. |
| REVIEW-9 | One dependency per change | Changelog read, package isolated, suite before and after, lockfile diff reviewed, never hand-edited. |
| REVIEW-10 | Test and infrastructure work leaves shipped code alone | No change to shipped code without an explicit ask. Negative-test probes run in a worktree or a temporary repository. |