Claude Code PR review prompt: read the diff like a senior dev

A weak AI review comments on variable names and misses the missing auth check. A senior reviewer starts somewhere else: what is this PR trying to do, does the diff do that, and what breaks if it's wrong? This work order makes Claude review in that order. It stays read-only, reads beyond the changed lines, and labels every finding so you know what actually blocks the merge.

The work order

Copy it, fill in the [brackets], and paste it into Claude Code. It also works in Cursor's Agent mode.

Review a PR like a senior dev Claude Code · code review

Review pull request [number or branch] as the senior engineer who gets paged if it breaks.
Read only. Don't edit files, push, or post comments anywhere.

Get the change with: [gh pr diff 123 / git diff main...feature-branch]
Also read the PR description and linked issue: [paste or link]

Before judging the code, tell me in three lines what this PR is trying to do and whether the diff actually does that. Flag anything in the diff the description doesn't mention.

Then review. Read the surrounding code where you need to, not just the changed lines.
- Correctness: wrong conditions, off-by-one, null or empty input, error paths that swallow failures, races.
- Callers: who else uses what changed, and will they still work?
- Data: migrations, backfills, anything that can't be rolled back.
- Security: input validation, permission checks, secrets, personal data in logs.
- Tests: would a test fail if the main change were reverted? Name the missing cases.
- Fit: does it follow patterns already in this codebase, or bring in a new one?

Write each finding as:
[blocker | should fix | nit] file:line. What's wrong, why it matters, suggested fix.

Skip style points the linter already catches. If something looks off but you aren't sure, say so and say what would confirm it. End with approve, approve with changes, or request changes, plus the one thing you'd most want the author to fix.

Run it in a fresh session, not the one that wrote the code. A reviewer that watched the code being written tends to agree with it.

Variations

Variation 1: Review your own branch before opening the PR Self-review

I'm about to open a PR from this branch. Compare it with [main] and review it the way my strictest teammate would.

Also look for leftovers: debug logging, commented-out code, TODOs I added, test files I changed, and files that don't belong in this PR. List findings by severity. Then draft a PR description with what changed, why, how to test it, and what reviewers should look at first.

Variation 2: A big PR, reviewed in passes Large diff

This PR touches [N] files. Don't review it all at once.

First, group the files by purpose: feature code, tests, config, generated files, and refactor noise. Tell me which groups need a careful read and why. Then review the risky groups one at a time, using the same severity labels, and wait for me after each group.

Large diffs are where reviews quietly get shallow. Splitting them up keeps attention on the files that can actually break production.

Variation 3: Work through review comments on your PR Author side

Here are the review comments on my PR: [paste]

For each one, say whether you agree, what change you'd make, and where (file:line). Put the comments that need a decision from me in a separate group. Don't change any code until I confirm the list.

When to use it

You're reviewing a teammate's PR and want a second pass before you approve.
You're the only reviewer on a small team and want a checklist that doesn't get tired.
Before opening your own PR, with the self-review variation.
It doesn't replace a human approval on risky changes. Use it to find what to look at.

What good output looks like

A short summary of intent at the top, and a call on whether the diff matches it.
Findings with file:line and a severity label, blockers first.
At least one point about code outside the diff, such as a caller or a migration.
Honest uncertainty: "looks like X, confirm by checking Y" rather than confident guesses.
Few or no nits. If half the list is naming, the prompt was ignored.

Common mistakes

Giving it only the diff and no description, so it can't tell intended changes from accidents.
Letting it post comments or push fixes. Keep review read-only and decide yourself what goes on the PR.
Treating "no blockers found" as approval. It's a second opinion, not a sign-off.
Reviewing in the same session that wrote the code.
Asking for "any issues" with no categories. You'll get style notes and miss the data migration.

Need a different prompt? Describe your coding goal and get ranked prompts with quality, match & confidence scores.

Rank prompts for my goal →

More Claude Code work orders

Related prompts in the library

FAQ

Can Claude Code post the review on GitHub for me?

It can run the gh command line tool if you allow it. This prompt keeps it read-only on purpose so you read the findings first and post only the ones you agree with. Claude Code also has built-in review commands and a GitHub integration; this prompt is for when you want control over the checklist.

How do I give Claude Code the PR diff?

From the repo, have it run gh pr diff with the PR number, or git diff main...branch-name for a local branch. You can also paste the diff, but letting it read the repo means it can check callers outside the diff.

Will it catch security problems?

It will catch common ones like missing input validation or permission checks if you ask, which the prompt does. It isn't a security audit. For sensitive code, follow up with a dedicated security review prompt and a human who knows the system.

Does this work for reviewing code in Cursor?

Yes. Start a new Agent chat, paste the prompt, and point it at the branch. The severity format and read-only rule work the same way.