PR Review Prompts: 14 Templates for AI-Assisted Code Review

AI PR review prompts that surface real issues — diff-scoped, change-aware, blast-radius aware. 14 templates for security / perf / tests / docs / risk.

Published: May 19, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

“Review this PR” gives you the same generic checklist regardless of what changed. A good PR review prompt is diff-scoped (only what changed), aware of blast radius (touches auth? schema? public API?), and produces actions, not paragraphs.

Who this is for

Tech leads using AI as a first-pass reviewer, indie devs doing solo PRs, staff engineers building review automation around Claude Code / Codex, anyone trying to make AI feedback actually merge-blocking.

When not to use these prompts

Don’t use these on PRs you didn’t skim first — AI review without human framing tends to nitpick formatting and miss the structural change.

Prompt anatomy / structure formula

Every PR review prompt should carry six elements:

Role: who the AI plays (release captain / QA lead / SRE / staff engineer).
Context: repo / framework / runtime / branch / diff / failing logs.
Goal: one concrete deliverable — checklist, plan, test file, review notes, root cause, ticket list.
Constraints: what AI MUST NOT do (don’t auto-fix, don’t silently rewrite, don’t guess versions).
Output format: numbered findings, markdown table, JSON schema, unified diff, or runnable code.
Examples / signal: 1-2 examples of “good” output, or what bad output looks like.

Best for

First-pass review before requesting a human reviewer
Security / perf / accessibility passes on a single diff
Auto-generating a PR description from the diff
Catching forgotten test / doc / migration / changelog updates
Blast-radius assessment before merge

14 copy-ready prompt templates

1. Diff-scoped first-pass review

You are a senior engineer reviewing this PR. Read ONLY the diff (not the whole files). Surface the top 5 issues by impact, not the first 5 you see. For each: (a) file:line, (b) severity (Critical / High / Med / Low), (c) one-line description, (d) suggested fix in ≤ 30 words. Skip cosmetics — no whitespace / import-order comments.

2. Blast-radius assessment

Assess BLAST RADIUS of this PR. Answer: (1) Does this touch auth / payments / schema / public API? (2) Is the change reversible in < 5 minutes? (3) Which other teams' code depends on the modified surfaces? List the dependency, file:line of import. (4) Should this be feature-flagged?

3. Test coverage gap on the diff

For the new / changed code in this diff, list the test gaps: (1) New branches without a test, (2) Modified branches whose existing test still passes against both old and new behaviour (i.e., the test doesn't prove anything), (3) Error paths added without tests. Don't propose tests for unchanged code.

4. PR description draft

Generate a PR description from this diff. Sections: (1) WHY (the problem in 2-3 sentences), (2) WHAT (bullet list of changes, ≤ 6 bullets), (3) RISK (one paragraph: what could break), (4) ROLLBACK (one sentence). Skip "How" — the diff shows that. Keep title ≤ 70 chars.

5. Security pass on the diff

Audit ONLY this diff for security issues: (1) New user input that reaches DB / shell / template / fetch without validation, (2) Secrets introduced, (3) Auth checks removed or weakened, (4) Logging that now leaks PII / tokens. Severity each. Ignore the rest of the codebase in this pass.

6. Performance regression check

Look at this diff for performance regressions: (1) New synchronous I/O in hot paths, (2) N+1 patterns introduced (loop + DB call inside), (3) New lodash / heavy import imported eagerly, (4) React: new context provider that wraps too much / unstable deps in `useMemo`. File:line + reason.

7. Forgotten-update detector

For this diff, list FORGOTTEN updates: (1) Changed an env var? Update `.env.example` and docs, (2) Changed an API route? Update OpenAPI / client SDK, (3) New migration? Update rollback / seed, (4) New feature? Update changelog / readme, (5) Changed a type? Update consumers. Return checklist with each item resolved / missing.

8. “Is this PR too big?” splitter

Assess whether this PR should be split. Criteria: ≥ 500 LOC OR ≥ 3 unrelated concerns. If yes, propose a split plan: PR-A (foundation, no behaviour change), PR-B (the actual feature), PR-C (cleanup). For each, list which files belong. Don't propose split if not needed.

9. Backwards-compat check

Check this diff for backwards-compatibility breaks: (1) Renamed / removed public exports, (2) Changed function signatures still imported elsewhere, (3) Changed JSON / DB column names, (4) Bumped major version of a published package. For each: list callers / consumers that need to update.

10. Reviewer-prompt for a humans-only pass

You're writing a Slack-length message to a human reviewer. Summarize this PR in 4-5 sentences so they know what to focus on. Highlight: the one decision that needs a second opinion, the one risky line, the rest is "fine to skim". Tone: peer to peer, no emojis.

11. Migration / DB-change red flags

Audit DB / migration changes in this diff: (1) DROP / RENAME without backfill, (2) NOT NULL added to large table without default, (3) Index missing on new FK, (4) Migration not idempotent on retry. File:line + severity + safe-deploy strategy.

12. Accessibility-on-diff

For UI changes in this diff, check accessibility: (1) New interactive element without keyboard handler, (2) Missing `aria-label` / accessible name, (3) Colour contrast change worsened on the modified components, (4) Loss of focus order. Skip unchanged UI.

13. AI-disclosed PR template

Useful when AI wrote most of the code — keeps reviewers informed.

Generate a PR description that discloses AI assistance honestly: (1) Which parts were AI-written / AI-reviewed / human-written, (2) Where the human verified outputs, (3) Any tests the human wrote vs AI generated. Keep it short and factual. No marketing language.

14. Re-review after fixes

Re-review this PR. Focus ONLY on diffs that changed since the last review at SHA `{oldSha}`. Confirm each previously-raised issue is resolved (or explicitly punted with a ticket link). Don't re-raise unchanged code — that was already discussed.

Variables to swap: oldSha

Common mistakes

Letting AI review the entire repo instead of the diff — drown in noise.
Accepting AI nitpicks (whitespace, import order) — desensitises real reviewers.
No severity scale — every comment looks equally urgent.
Not asking for blast radius — you miss the auth / schema landmines.
Auto-applying suggestions — they often have subtle bugs.
Reviewing AI-generated tests as if a human wrote them — they often pass against both old and new code.
Skipping the “forgotten updates” pass — changelogs / env.example always rot.

How to push results further

Always run diff-scoped review first. Whole-file review is a different prompt.
Severity → Critical / High / Med / Low. Reviewers triage on this.
Demand file:line evidence. No evidence = hallucination.
Run the “forgotten-update detector” template on every PR — it catches the boring stuff humans miss.
For risky PRs (auth / payments / migrations) run security + blast-radius + migration prompts together.
Disclose AI authorship in the PR body so reviewers calibrate.
Save your favourite review prompt as a .claude-code/review.md so it travels with the repo.

FAQ

Can AI replace a human reviewer?: No. AI catches the boring stuff (forgotten env, missed tests, naming) so humans can focus on design and intent.
Does AI miss real bugs?: Yes — especially semantic ones. Use it as a first pass, not a gate.
How do I avoid nitpick spam?: Tell the prompt to “skip cosmetics” and demand ≤ 5 issues sorted by impact.
Should I let the bot post inline comments?: Only with a confidence filter (severity ≥ High). Otherwise the comment stream becomes noise.
How big a PR can AI review?: Up to ~ 600 LOC reliably. Beyond that, split into chunks per file or per concern.
Can I trust AI on security PRs?: Use it for known-pattern checks (XSS, secrets, missing auth) but always have a human sign off.

Tags: #Prompt #Coding #Code review #PR review