Engineering

Pull Request Review Prompt

Review the change as it will land: cross-file impact, deployment risk, migration safety — plus whether the PR does what its description says.

Open in Code Review Prompt Generator

Overview

A pull request is more than its diff: it lands across files, deploys in an order, and sometimes migrates data. This setup runs PR scope — which adds eight change-specific criteria to the correctness review: breaking changes to public contracts, backward compatibility of serialized data, regression risk, hidden coupling between changed files, deployment ordering and rollback, migration compatibility windows, whether the PR is small enough to review honestly, and whether the description matches the actual change.

How to use this resource

Paste the full diff, not file-by-file

Cross-file criteria only work when the model sees the files together.
Weigh the compatibility findings first

Breaking-change and migration findings are the ones that hurt after merge — code-style findings can wait.
Check the description-honesty finding

A PR that does more than it says is a review evasion — the contract flags it explicitly.

Why This Works

PR-scope criteria cover what diff-blind reviews structurally cannot see
The one-thing rule flags unrelated changes that ride along unreviewed
Deployment and migration criteria review the landing, not just the code

Best for

Teams whose human reviewers are stretched thin
PRs that touch contracts, schemas, or serialized data
Repos where deploy ordering and rollback paths matter

Not for

Replacing the human reviewer — this is the second pair of eyes, not the approval authority
Reusable PR description templates — that's the Prompt Template Builder's pr-review-template

Use cases

Acting as the second reviewer on team PRs
Catching the cross-file coupling a per-file review misses
Checking that the PR description matches what actually changed

FAQ

What makes this different from reviewing each file in the PR separately?

It adds a Cross-file impact criterion that hunts "hidden coupling between the changed files," plus deployment-ordering and migration-window criteria a per-file pass structurally can't see. Because of that, the workflow tells you to paste the full diff together, not file by file. The generated prompt runs in your own assistant, which does the actual reviewing.

Can I merge based on the APPROVED verdict this prompt gives?

Treat it as a second pair of eyes, not the approval authority. The FINAL VERDICT (APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED) is based only on the findings the model listed, in your own assistant, which can miss things. A human reviewer still owns the merge decision; the verdict informs it rather than replacing it.

How does it catch a PR that does more than its description claims?

A dedicated criterion checks "whether the description matches what the change actually does," and checklist item 12 asks whether the code does what its name and comments claim. The workflow calls a description mismatch a review evasion and flags it, so unrelated changes riding along get tagged with a severity like [MAJOR] rather than sliding through.

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

Copy it as-is, or use Open in Code Review Prompt Generator to load it pre-filled and customize it with your own context.

REVIEW OBJECTIVE
Review this pull request as the second reviewer before merge.
Primary focus: correctness — find the ways this code produces wrong results or fails.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a full pull request — judge the change as it will land: across files, at deploy time, in production.

REVIEW CRITERIA
- Logic errors and inverted conditions
- Edge cases: empty, zero, negative, maximum, duplicate inputs
- Null/undefined/None handling before dereference
- Error paths: propagation, swallowed exceptions, partial failure states
- Concurrency: race conditions, unawaited async results, shared mutable state
- Breaking changes to public APIs or contracts
- Backward compatibility of serialized data, schemas, and protocols
- Regression risk in the touched code paths
- Cross-file impact: hidden coupling between the changed files
- Deployment risk: ordering, partial deploys, rollback path
- Migration risk: schema or data changes and their compatibility window
- Whether the PR is small enough to review honestly
- Whether the description matches what the change actually does

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Are inputs validated at the boundaries where they enter?
2. Are edge cases handled: empty, zero, negative, maximum-size inputs?
3. Any off-by-one errors in loops, slices, or range checks?
4. Is null/undefined handled before every dereference?
5. Do error paths return or propagate correctly — nothing swallowed silently?
6. Are async operations actually awaited and their failures handled?
7. Any race conditions on shared state or check-then-act sequences?
8. Are return values of fallible calls checked?
9. Are type coercions and implicit conversions intentional?
10. Are comparison boundaries correct (< vs <=, exclusive vs inclusive)?
11. Is there dead or unreachable code hiding an intent mismatch?
12. Does the code do what its name and comments claim it does?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Prioritize findings that matter; skip pure style nits unless they hurt readability.
- If something is done notably well, say so once — briefly.

FINAL VERDICT
- End with a verdict: APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the pull request here]

More resources from Code Review Prompt Generator

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Security Code Review Prompt

Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.

Engineering

Resource

API Review Checklist Prompt

Architecture review for the public surface: abstractions that earn their place, dependency direction, seams, and the patterns the codebase already has.

Engineering

Resources that pair well

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Compare Two ChatGPT Prompts

A side-by-side way to decide between two ChatGPT prompt drafts — scored on clarity, specificity, output control, and risk instead of gut feeling.

Prompt Engineering

Related tools

Tool

Code Review Prompt Generator

Generate code review prompts for any scope — snippet, file, diff, or full pull request — with focused review rules.

Coding Workflows

Guides for this resource

Guide

How to Review AI-Generated Code Without Missing Risky Changes

AI-written code usually compiles and passes a quick test while hiding the real risks — a missing auth check, a destructive update, an untested edge case. Here's a review path that surfaces them before you merge.

Software Development with AI

Tip: Save time by exploring related resources and tools that integrate with this resource.