Claude/ChatGPT (or Cursor) Prompt to Run a Senior Code Review on a Diff

What this prompt does

It points a model at the output of git diff [base]..HEAD and asks for the review a tired-but-honest staff engineer would give: correctness, security against the OWASP Top 10, performance traps like N+1 queries and runaway memory, readability, and test coverage. Scoping to the diff is the whole trick — the model only judges what you actually changed, so it stays anchored to real lines instead of inventing problems in code it never saw.

The output contract is what makes it usable. Three ranked sections — Must fix (blocks merge), Should fix (follow-up PR), Nits — force triage instead of dumping every observation as equally urgent. Demanding file:line plus a minimal fix turns vague advice into something actionable in seconds, and "cite evidence, no praise, no filler, max 15 items" strips the congratulatory padding that makes most AI reviews unreadable.

When to use it

• Before you open a PR, to catch blockers while the change is still cheap to fix.
• As a second reviewer on a branch nobody else has time to look at.
• On a large diff where you want the genuinely merge-blocking issues surfaced first.
• During a security-sensitive change — auth, file uploads, query building, deserialization.
• After an AI agent wrote the code, to audit it with a stricter, evidence-bound pass.
• In CI as a pre-merge gate, piping the diff in and failing on any Must-fix item.

Example output

## Must fix (blocks merge)
1. app/Http/Controllers/OrderController.php:48 — raw `$request->id` interpolated
   into a DB::select string (SQL injection). Fix: bind it — `where('id', $id)`.
2. app/Services/Report.php:71 — N+1: `$orders` looped with `$o->customer->name`.
   Fix: eager load — `Order::with('customer')`.

## Should fix (follow-up PR)
3. app/Jobs/SyncFeed.php:33 — no retry/backoff on the HTTP call; a 500 loses the job.

## Nits
4. app/Models/Order.php:19 — `$casts` missing `total => 'decimal:2'`.

Pro tips

• Set [base] to your real merge target — main, develop, or a release branch. The review is only as honest as the diff; the wrong base hides or invents changes.
• For a feature branch, origin/main beats main so you compare against what's deployed, not a stale local ref.
• If the diff is huge, run --stat first, then review the highest-risk files individually — context limits silently truncate giant diffs and you lose the tail.
• Pair it with your test suite: take each Must-fix item, write a failing test that proves it, then fix. The review finds the bug; the test stops it returning.
• Tune the lenses for the change — drop "performance" on a docs-only diff, or add "race conditions" and "idempotency" when touching queue jobs or webhooks.