Save as .claude/skills/code-review/SKILL.md in a repository, or under ~/.claude/skills/code-review/SKILL.md to have it everywhere. The copy button takes the whole file, frontmatter included.

---
name: code-review
description: Review a diff or pull request and report what actually matters, ranked by consequence. Use when asked to review code, check a pull request, look over a change before merge, or say whether a diff is safe to ship.
---

# Code review

Review the change, not the file. Everything you say should be about what this
diff does differently from what was there before.

## Read before you comment

1. Read the whole diff once without writing anything.
2. Work out what the change is trying to do. If you cannot tell from the diff
   and its description, say so first. A review of a change you have not
   understood is noise.
3. Only then go back and comment.

## Priority order

Report findings in this order, and stop padding once the real ones are out.

### 1. Correctness
Does it do what it claims. Look specifically at:

- Boundaries: empty input, a single item, the last index, zero, negative.
- Error paths. Most bugs live in the branch nobody ran.
- Anything that was previously handled and is now not. A deleted check is a
  finding even when the deletion looks tidy.
- Concurrency: shared state, ordering assumptions, retries that are not
  idempotent.

### 2. Security and data loss
Unvalidated input crossing a trust boundary, a credential in source, a query
built by string concatenation, authorisation checked in the caller rather than
the function, anything that deletes or overwrites without a guard.

These are never "nits". Say so plainly.

### 3. Behaviour nobody asked for
Scope creep, a changed default, a renamed field, an altered response shape.
These break callers quietly and are easy to miss in a large diff.

### 4. Tests
Does a new behaviour have a test that would fail without the change. A test
that asserts the implementation back at itself is worth less than no test,
because it has to be rewritten whenever the code is.

### 5. Clarity
Naming, dead code, a function doing three things. Real, and last.

## What not to do

- **Do not restate the diff.** "This adds a null check" is not a review.
- **Do not list style points as findings** when a formatter or linter already
  owns them.
- **Do not invent problems to look thorough.** If the change is fine, say it is
  fine. A review with three real findings beats one with fifteen padded ones,
  because the three get read.
- **Do not comment on untouched code** unless the change makes it wrong.

## Say how sure you are

Mark each finding:

- **Bug** — this is wrong, here is the input that breaks it.
- **Risk** — this will probably bite, here is when.
- **Question** — I cannot tell from the diff; it may be fine.
- **Nit** — optional, take it or leave it.

Never present a guess as a bug. If you have not traced the path, it is a
question. Guesses dressed as findings are the fastest way for a reviewer to
stop being trusted.

## Report back

1. One sentence: what this change does.
2. Anything blocking, with the failing case spelled out.
3. Non blocking findings, grouped.
4. A clear verdict: safe to merge, or what has to change first.