---
name: diff-review
description: Reviews the current branch's changes against its base branch for correctness bugs, unhandled errors, broken edge cases, changed contracts and missing tests. Use when the user asks to review their changes, check a diff before a pull request, or asks whether a branch is ready to merge.
---

# Diff review

Review the changes on the current branch. Report real problems with evidence. Do not edit files unless the user asks.

## 1. Establish the change set

1. If the user named a base branch (for example in `$ARGUMENTS`), use it. Otherwise try, in order: `origin/main`, `origin/master`, `main`, `master`. If none exist, ask.
2. Run `git merge-base HEAD <base>` and use that commit as the base.
3. Run `git diff --stat <merge-base>` to list changed files, then `git diff <merge-base>` for the full diff. This includes uncommitted work in the working tree.
4. If the diff is empty, say so and stop.

## 2. Build context before judging

- Read each changed file in full, not only the hunks.
- For every function, method, type or exported constant whose signature or behavior changed, search for its callers (`grep -rn` or the Grep tool) and read them.
- Find the tests that cover the changed code. Note which changed behavior has no test.

## 3. Checklist

Work through each item for every changed file:

- **Logic**: inverted or incomplete conditions, off-by-one, wrong variable, integer/float mistakes, missing `await` or unhandled promise, early return that skips cleanup.
- **Inputs**: empty collections, null/undefined/None, missing keys, very large inputs, unicode, negative numbers.
- **Errors**: exceptions swallowed silently, error paths that leave partial state, retries without limits, missing timeouts on network calls.
- **Contracts**: changed function signatures, response shapes, database columns, config keys or environment variables, and whether every caller and consumer was updated.
- **Concurrency**: shared mutable state, check-then-act races, non-idempotent handlers that may be retried.
- **Resources**: files, sockets, DB connections, event listeners or timers that are opened but not closed.
- **Tests**: new behavior without a test, assertions weakened or deleted, tests that no longer test what their name says.

Skip formatting, import order and naming preferences that the project's linter or formatter already enforces.

## 4. Report

Use this structure:

```
## Review of <branch> against <base> (<n> files)

### Blocker
- `path/to/file.ext:LINE` - <what goes wrong, in which scenario>. Fix: <specific change>.

### Should fix
- ...

### Nit
- ...

### Not covered by tests
- <behavior> in `path:LINE`
```

Rules:
- Every finding needs a file and line and a concrete failure scenario.
- If you could not confirm a problem by reading the code, prefix it with "Unverified:".
- Omit empty sections. If there are no findings, say the diff looks correct and list what you checked.
- Keep each finding to two or three sentences.