# PR review ritual

A review is a claim: "I understand what this change does, and here is what it risks." This skill makes an agent earn that claim before it writes a single comment.

## When to use
- On every pull request, as a first pass before a human reviewer.
- In Claude Code on a local branch before opening the PR.

## Input
The diff, the PR description, the linked issue if any, and — when available — the CI result and the files' git history.

## The ritual
1. **Read the description, then the diff, then the description again.** Note every place where they disagree. A diff that does more than the description says is the most common finding.
2. **Second read, for intent.** For each hunk, say in one sentence why it exists. If you cannot, that hunk needs a comment or a question — not a guess.
3. **What would break.** For every changed function, list the callers you can see and the inputs that changed meaning: null, empty, huge, concurrent, retried. Trace at least one path end to end.
4. **Tests.** Does a test fail if this change is reverted? If no test covers the new behavior, say which case is missing — specifically, with the input.
5. **Write comments.** Each comment quotes the line, states the risk, and, when you have one, offers the fix. Questions are allowed and are better than wrong assertions.

## Severity ladder
- **Blocker** — data loss, security, a broken invariant, a public API change without a note.
- **Should fix** — a bug on a reachable path, a missing test for new behavior, an unclear name that will mislead the next reader.
- **Consider** — a simpler way, a duplicated helper, a comment that no longer matches the code.
- **Nit** — do not write these. Formatting, import order and whitespace belong to the linter; if the repo has no linter, say that once at the top, not per line.

## Rules
- Never approve. You are the first reader, not the owner. End with a summary and the list of blockers.
- Never rewrite the PR in a comment. Show the smallest change that resolves the point.
- Quote, don't paraphrase — a comment the author cannot find is noise.
- If the diff is over ~800 lines, say so first and review the riskiest files, named.

## Output format
```
## Summary
Adds retry with backoff to the webhook sender. The description says "retries 3×"; the code retries 5× (sender.php:41).

## Blockers (1)
- sender.php:58 — `sleep()` inside the request cycle; a slow webhook now blocks the worker for up to 31 s.

## Should fix (2)
- ...

## Missing tests
- retry gives up after the last attempt and records the failure (no test asserts the failure path)
```

## License
MIT