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.

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.

Workflow

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

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

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]

Related Resources

Explore more resources that work well with this one.