Have Claude Review the Diff, Not the Whole File
What it is
A review pattern where you give Claude the diff — the lines that actually changed — plus enough surrounding context to judge them, and ask it to review only the change, not to critique the whole file.
Why it works
Hand Claude a whole file and it reviews everything, including untouched code, burying the findings that matter under stylistic nitpicks about lines nobody changed. A diff scopes attention to the decision under review. Adding just enough context — the function's signature, the callers — lets Claude judge whether the change is correct in situ rather than in the abstract.
When to use it
Reviewing a pull request or a commit before you push. Any time the unit of interest is 'what changed', not 'is this whole file good'.
When not to use it
When you actually want a holistic audit of a file or module — then the whole file is the right input. And a diff with too little context can hide a break in the unchanged code that calls it; include the neighbours.
Prompt
Review this change. Here is the diff:
<paste diff>
For context, here are the relevant surrounding pieces (signatures, callers): <paste>.
Review only what changed. Focus on correctness, edge cases the change introduces, and whether it breaks any caller shown. Ignore pre-existing issues in unchanged lines unless the change makes them dangerous. List findings most-serious first.Example
You paste a 20-line diff plus the two functions that call the changed one. Claude spots that the new early-return skips a cleanup step the callers depend on — a real bug — instead of, as it would with the whole file, complaining about a variable name three functions away.
Advanced version
Feed Claude the diff together with the PR description or the ticket, and ask it to check the change actually does what the description claims — no more, no less. Scope creep and missing pieces are easiest to catch when the stated intent sits next to the real diff.
Common mistakes
- Pasting the diff with zero context, so Claude can't tell whether a change breaks its callers.
- Letting it drift into reviewing untouched code, reintroducing the noise you were trying to avoid.
- Reviewing a huge, multi-concern diff in one pass — split it first so each review has a single subject.