Web Development · Quality & performance
The Best Prompt for Code Review
The best prompt for code review tells the model what the change is meant to do, then asks for findings in priority order: correctness and security before design, design before style. This prompt requires a severity label, a location, a reason and a concrete fix for every finding, and it makes the model say what it could not judge from the diff alone. The result reads like a useful pull request review, not a list of style preferences.
Pull Request Code Review Prompt
Reviews a diff the way a careful senior engineer would: intent first, findings ranked by severity, each tied to a line with a suggested fix.
- Works with
- ChatGPT, Claude, Gemini, Cursor
- Difficulty
- Intermediate
- Complexity
- Multi-part reply
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
# Role You are a senior engineer reviewing a pull request. Your aim is to help the author ship a correct change and to leave the codebase healthier than before, not to demonstrate thoroughness. # The change - What it is supposed to do: [What the change is supposed to do] - Language, framework and versions: [Language, framework and versions] - Where this code runs and what is at stake: [Where it runs and what is at stake] - Team standards to apply: [Team standards] - Focus for this review: [Review focus] # Diff <diff> [Diff] </diff> # How to review 1. Restate, in two sentences, what the diff actually does. If that differs from the stated intent, say so first; it is the most important finding. 2. Read in this order and stop to report as you go: correctness and edge cases; security and data handling; error handling and failure behavior; concurrency and performance where relevant; design and fit with surrounding code; tests; naming and readability. 3. For tests, say which behaviors in this change are untested, not just whether tests exist. # Findings Give each finding: - a severity: BLOCKING (bug, security issue or data loss), SHOULD FIX (likely problem or real maintainability cost), NIT (optional polish), or QUESTION (you need information to judge); - the file and line or hunk; - what is wrong and the concrete consequence, in one or two sentences; - a suggested fix, as code when it is short. # Constraints - Review only what the diff shows. If a concern depends on code you cannot see, raise it as a QUESTION and name the file or function you would need. - Do not report an issue you cannot tie to a specific line. - Do not invent the behavior of functions, libraries or APIs that are not shown. Say when you are unsure. - Skip anything a formatter or linter would catch, unless the team standards say otherwise. - No more than five NITs. Merge duplicates of the same issue into one finding with all locations. - If the change is sound, say so plainly. Do not manufacture findings. # Output format 1. Summary of what the change does. 2. Verdict: approve, approve with changes, or request changes, with a one-line reason. 3. Findings, grouped by severity in the order above. 4. What I could not assess from this diff. 5. One thing done well, only if it is true and specific.
Use it when you are
- Reviewing your own pull request before asking a teammate for their time
- Getting a second pass on a change in a language or framework you know less well
- Working alone on a project with nobody available to review
- Checking a diff produced by an AI coding tool before you commit it
Why this prompt works
Intent is checked before quality
A reviewer who does not know what a change is for can only comment on how it looks. Supplying the purpose, and asking the model to restate what the diff really does, puts a mismatch between the two at the top of the review, where the most serious bugs tend to be found.
The reading order reflects what matters
Google's published review guidance places design, functionality and tests ahead of style, and this prompt orders its passes the same way. Correctness and security are examined first and naming last, so a long reply still leads with the findings that should block a merge.
Severity labels make the review usable
Twenty unranked comments leave the author to work out which three matter. Four fixed labels, a cap on nits and merged duplicates let you act on a review in order: fix what blocks, decide on the rest, answer the questions.
Every finding has a location and a consequence
Requiring a line reference and a concrete consequence filters out vague remarks such as "consider improving error handling". If the model cannot say where the problem is and what would go wrong, the prompt tells it not to report it.
Unknowns become questions, not accusations
A diff shows only part of the code. Models often assume that a helper does or does not validate its input and build a finding on that. The QUESTION label and the closing section on what could not be assessed keep those cases visibly separate from confirmed problems.
How to use it
- Write or paste the pull request description into the first field. Include the acceptance criteria if the change has them.
- Paste a unified diff with file names. For changes that depend on code outside the diff, add those functions below it.
- Remove credentials, keys and customer data before pasting anything.
- Choose a focus if you want depth in one area; leave it on full review for a normal pass.
- Handle BLOCKING findings first and verify each one yourself; then answer the QUESTION items, which often resolve into either a non-issue or a real bug.
- Treat the result as preparation for human review of anything important, not a replacement for it.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | For a large diff, review it in logical chunks, one per message, and ask for a combined verdict at the end. Very long pastes may be reviewed unevenly. |
| Claude | Expected to work | The diff is wrapped in XML-style tags, which Anthropic's guidance recommends for separating material from instructions. Add further tags, such as <related_file>, for any surrounding code you include. |
| Gemini | Expected to work | No model-specific adjustment needed. Paste the prompt as written. |
| Cursor | Expected to work | In a repo, replace the pasted diff with a reference to your working changes or branch diff. Because the editor can open surrounding files, tell it to resolve its own QUESTION findings by reading the code it names before reporting them. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: An illustrative case: a developer wants a pre-review of a change adding rate limiting to a password reset endpoint.
# Role You are a senior engineer reviewing a pull request. Your aim is to help the author ship a correct change and to leave the codebase healthier than before, not to demonstrate thoroughness. # The change - What it is supposed to do: Adds rate limiting to POST /auth/password-reset: at most five requests per email address per hour. Over the limit, return 429. Must not reveal whether an email is registered. - Language, framework and versions: TypeScript 5, Node 22, Express, Redis for counters, Vitest - Where this code runs and what is at stake: Public authentication service; abuse and account enumeration are concerns - Team standards to apply: Errors go through AppError. No direct Redis calls outside services/. Every new branch needs a test. - Focus for this review: Full review # Diff <diff> (A unified diff of about 120 lines touching routes/auth.ts, services/rateLimiter.ts and tests/auth.test.ts) </diff> # How to review 1. Restate, in two sentences, what the diff actually does. If that differs from the stated intent, say so first; it is the most important finding. 2. Read in this order and stop to report as you go: correctness and edge cases; security and data handling; error handling and failure behavior; concurrency and performance where relevant; design and fit with surrounding code; tests; naming and readability. 3. For tests, say which behaviors in this change are untested, not just whether tests exist. # Findings Give each finding: - a severity: BLOCKING (bug, security issue or data loss), SHOULD FIX (likely problem or real maintainability cost), NIT (optional polish), or QUESTION (you need information to judge); - the file and line or hunk; - what is wrong and the concrete consequence, in one or two sentences; - a suggested fix, as code when it is short. # Constraints - Review only what the diff shows. If a concern depends on code you cannot see, raise it as a QUESTION and name the file or function you would need. - Do not report an issue you cannot tie to a specific line. - Do not invent the behavior of functions, libraries or APIs that are not shown. Say when you are unsure. - Skip anything a formatter or linter would catch, unless the team standards say otherwise. - No more than five NITs. Merge duplicates of the same issue into one finding with all locations. - If the change is sound, say so plainly. Do not manufacture findings. # Output format 1. Summary of what the change does. 2. Verdict: approve, approve with changes, or request changes, with a one-line reason. 3. Findings, grouped by severity in the order above. 4. What I could not assess from this diff. 5. One thing done well, only if it is true and specific.
What a good response should contain
- A two-sentence restatement of what the diff does, noting any gap from the stated limit or response behavior
- Findings on the kinds of issue this change invites, such as a non-atomic counter update, inconsistent email normalization or responses that differ for registered and unregistered addresses, each tied to a line
- A note on which behaviors are untested, for example the request that crosses the limit and the reset of the window
- QUESTION items for anything outside the diff, such as how the Redis client handles connection failures
- A verdict with a one-line reason and a short section listing what could not be assessed
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- The model sees only what you paste. Problems that arise from how the change interacts with the rest of the system can be missed.
- It can report issues that are not real, especially about library behavior. Verify a finding before acting on it.
- It does not run the code or the tests, so it cannot confirm that anything works.
- A clean review is not evidence of security. Sensitive changes still need review by someone qualified.
- Check your organization's policy before pasting proprietary code into an external tool.
Alternative prompts
Coding
Behavior-Preserving Refactoring Prompt
Restructures code in small, named steps while holding its observable behavior fixed, and reports anything it could not prove equivalent.
- ChatGPT
- Claude
- Gemini
- Cursor
Coding
Bug Diagnosis Prompt
Give the model the error, the code and what you expected. It ranks likely causes by evidence, tells you how to confirm each, and proposes a minimal fix.
- ChatGPT
- Claude
- Gemini
- Cursor
Coding
Unit Test Writing Prompt
Produces a case inventory first, then readable tests that check behavior at the boundaries, with suspected bugs flagged instead of encoded as passing.
- ChatGPT
- Claude
- Gemini
- Cursor
Web Development
Technical Specification Prompt
Interviews you briefly, then drafts a reviewable spec: goals and non-goals, design, alternatives, rollout, risks and open questions.
- ChatGPT
- Claude
- Gemini
Related resources
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Guide
How to Write a Good AI Prompt
The five parts of a complete prompt (goal, context, task, constraints, output format), with a worked rewrite and a pre-send checklist.
Technical guide
How to Test AI Prompts
A seven-criterion rubric and a nine-field test record for evaluating prompts, plus why this site describes results in words and publishes no scores.
Frequently asked questions
Can AI code review replace a human reviewer?
No. It is useful for catching mistakes before a person looks, and for changes nobody else is available to read. A human reviewer brings knowledge of the system's history, of what the team has agreed and of what the product needs, none of which is in the diff.
How much code can I paste at once?
Reviews are most reliable on a focused change that a person could also review in one sitting. For a large pull request, split it by commit or by area and review each part, then ask for an overall verdict. Include surrounding functions when the diff alone is ambiguous.
Why does the prompt limit nits to five?
Because style comments are the easiest thing for a model to produce and the least valuable to read. Capping them keeps attention on correctness and design. If you want a full style pass, a linter and formatter will do it more consistently.
What if I disagree with a finding?
Reply with your reasoning and the relevant code the model did not see. A sound finding should survive that; many disappear once the missing context is supplied. Do not accept a change you do not understand because the review suggested it.
Sources and references
- How to do a code review — Google Engineering Practices
- Prompt engineering overview — Anthropic
Was this prompt useful?
No account needed. Do not include personal information.