Claude Prompts for Code Review
28 copy-paste prompts for reviewing a diff: scope, correctness, security, tests, migrations, comments a human can post, and a check of the fix. Claude does not approve the merge.
Last updated September 26, 2026
What this page is for
A code-review prompt is a brief for a reviewer, not a request to implement the feature. Claude is useful when the diff is in the message and the contract is explicit. Labeled blocks keep the goal, the patch, and the tests from blending into one story.
Use a normal Claude conversation when you can paste the diff. If your workspace includes Claude Code, the same briefs work as the instructions for /code-review or a GitHub review. Anthropic documents those surfaces separately, and Team or Enterprise availability can differ from a personal chat. Check the account you are using. Do not assume a review ran because a prompt exists.
For the gates around the prompts, use How to Use Claude to Review Code. For writing the change itself, use How to Use Claude for Coding or How to Use AI for Coding. This page stays on review prompts.
Which prompt to run
| Job | Paste | Claude must not |
|---|---|---|
| Scope the diff | Contract and the patch | Name bugs before it lists missing files |
| Check correctness | Contract, diff, and a failing example if you have one | Return a style rewrite |
| Security pass | Trust boundary plus the diff | Write exploit steps or invent a control |
| Missing tests | Diff and the tests that already exist | Mock away the behavior under test |
| Schema or API | Before and after shapes, or the migration | Call every change breaking |
| Review the fix | Original finding, fix diff, and test result | Start a new wishlist |
How to run one review
Run the scope prompt first. If it says NEED CONTEXT, add the missing interface or stop. Then run correctness, then security, then tests. Post comments only for findings you opened in the code. A comment that quotes the wrong line trains the team to ignore the next one.
Keep secrets out of the prompt. If a token is already in the diff, rotate it. The security prompt is written to tell you to rotate, not to echo the value. High-impact paths, including authentication, payments, and deletion, still need a human owner even when the model returns no material finding.
Copilot review is a different product with a different prompt shape. See GitHub Copilot for code review. Broader coding prompt collections are on coding prompts and Claude prompts.
28 copy-paste Claude prompts
Replace every bracket. Delete a block you cannot fill. If a finding has no quote from the diff, do not treat it as a bug.
Scope the diff before judging it
The first prompts force a contract and a boundary. Claude should say what it cannot see before it names a defect.
<contract> [what the change must do, what must stay the same, and how you will know it worked] </contract> <diff> [paste a focused diff] </diff> Restate the contract in five lines. List files in the diff and files you would need but do not have. Do not report bugs yet. End with READY or NEED CONTEXT.
<diff> [paste] </diff> Map the change: entry point, data it reads, data it writes, and the caller that is not in the diff. Mark each item OBSERVED or INFERRED. If the diff is too large to review in one pass, propose three slices and which slice to review first.
This change claims to fix [bug or ticket]. Here is the failing example and the diff. <example> [input, actual, expected] </example> <diff> [paste] </diff> Say whether the diff touches the path in the example. If it does not, say OUT OF SCOPE and name the function that still handles that input. Do not propose a rewrite.
<non_goals> [formatting, renaming, and behavior that must not change] </non_goals> <diff> [paste] </diff> List hunks that violate a non-goal. Quote the hunk. Ignore style nits that are not in the non-goals. If none, say NO NON-GOAL VIOLATIONS.
Correctness against the contract
Ask for a few reproducible failures. A long list of preferences is a different prompt.
<contract> [paste] </contract> <diff> [paste] </diff> Return at most five correctness findings. For each: severity, file and line, quote from the diff, input that fails, why it breaks the contract, and whether this is OBSERVED or INFERRED. If a category is clean, say NO MATERIAL FINDING. Do not approve the change.
Trace this handler from request parsing to the response. Check empty, duplicate, malformed, and repeated inputs. Name the state that is the source of truth. <diff> [paste the handler and the type or schema it uses] </diff> Return a table: input, expected, what the code does, risk. Skip style.
Review error handling only. For each new failure path, say what the caller observes, whether the error is logged without secrets, and whether a partial write can remain. Quote the branch. <diff> [paste] </diff>
Look for off-by-one, null, timezone, and unit mistakes in this change. Quote the expression. Give one numeric example that would fail. If the units are not in the diff, write UNKNOWN instead of assuming. <diff> [paste] </diff> <units> [paste comments or types that define units, or NONE] </units>
Security and data handling
One pass, one trust boundary. This is triage of code you are allowed to review, not an exploit write-up.
<trust_boundary> [who is authenticated, what they may access, what is tenant-scoped] </trust_boundary> <diff> [paste] </diff> Review authorization only. For each sensitive action, quote the check or write MISSING CHECK. Do not include exploit steps. Do not invent a control that is not in the diff. Severity: blocker, high, medium, or low.
Review this diff for injection and unsafe use of user input. Cover SQL, shell, path, HTML, and redirects only where the diff touches them. Quote the sink and the source. If the input is validated earlier in a file I did not paste, label the finding QUESTION. <diff> [paste] </diff>
Secrets and logging review. List any token, password, key, or personal data that this diff reads, writes, or logs. Quote the line. Say REDACT, REMOVE, or OK with a reason. Do not repeat a secret if one is present. Tell me to rotate it instead. <diff> [paste] </diff>
File upload and tenant isolation review. What can a user in tenant A cause to happen to tenant B's data? Use only the diff and this data model. <data_model> [tables or types] </data_model> <diff> [paste] </diff> Return findings or NO MATERIAL FINDING. A human still has to verify high-impact issues.
Tests that would fail first
Ask for a test that fails on the current diff, not a test that repeats the implementation.
<diff> [paste] </diff> <existing_tests> [names and what they assert, or NONE] </existing_tests> List missing regression tests. For the highest-risk gap, write one test outline: arrange, act, assert, and the input that should fail before a fix. Do not mock away the behavior under test.
Here is a finding I accept: [finding]. Write the smallest regression test that fails before the fix and passes after it. Use the test style of this snippet: <test_style> [paste one existing test] </test_style> Do not include the production fix in the test file.
Review these tests against the contract. Which assertions would still pass if the feature were broken? Quote the weak assertion and the contract line it misses. <contract> [paste] </contract> <tests> [paste] </tests>
Concurrency and retry review. Identify duplicate delivery, double submit, or a lost update. Propose one test that runs the operation twice. If the diff has no shared state, say NOT APPLICABLE. <diff> [paste] </diff>
APIs, schemas, and migrations
Compatibility failures are easy to miss when the diff looks locally correct.
<api_before> [route, request, response] </api_before> <diff> [paste] </diff> List response fields and status codes that changed. Mark each BREAKING, ADDITIVE, or INTERNAL. Quote the line. Do not suggest a versioning scheme unless a break is real.
Review this migration. Order of operations, backfill, nullability, lock risk, and what happens if the job stops halfway. Quote the SQL or schema change. <migration> [paste] </migration> <app_diff> [paste the code that reads the new shape] </app_diff> Say whether the app and the migration can deploy in either order.
Feature flag review. What is the behavior when the flag is off, on, and missing? Quote the default. Name a caller that might ignore the flag. <diff> [paste] </diff>
Compare this client type with the server change. List fields the client sends that the server ignores, and fields the server requires that the client does not send. <client> [paste] </client> <server> [paste] </server>
Comments a human can post
The model drafts the note. You post it after you reproduce the issue.
Turn these verified findings into pull-request comments. One comment per finding. Include file, line, the failure, and a question. No praise, no approval, no style nits. I will post them myself. <findings> [paste findings you already reproduced] </findings>
Rewrite this review comment so it is specific and calm. Keep the defect. Remove sarcasm and any claim I have not verified. <comment> [paste] </comment> <evidence> [what I ran] </evidence>
Summarize this review for the pull-request description in under 120 words. Separate verified defects, open questions, and tests I ran. Do not say LGTM or approved. <notes> [paste] </notes>
I disagree with this finding. Argue only from the diff and the contract. Say whether the finding should be withdrawn. Do not invent a runtime trace. <finding> [paste] </finding> <diff> [paste] </diff> <contract> [paste] </contract>
The fix, dependencies, and an empty review
Close the loop on one finding, or say clearly that you found nothing material.
<original_finding> [paste] </original_finding> <fix_diff> [paste only the fix] </fix_diff> <test> [paste the new test and its result] </test> Does the fix address that finding? Did it weaken another check? Quote the lines. Do not start a new wishlist.
Dependency review. This diff changes [package] from [old] to [new]. Read the changelog notes I pasted and the call sites in the diff. List behavior changes that touch our code. If the changelog does not mention a risk, do not invent a CVE. <changelog> [paste] </changelog> <diff> [paste] </diff>
Second pass for maintainability, only after correctness and security are done. Name one abstraction that hides a rule, or say NO MAINTAINABILITY BLOCKER. Do not request a rewrite of working code. <diff> [paste] </diff>
Honest empty review. Using the contract and the diff, check correctness, auth, input handling, secrets, and missing tests. For each category write FINDING or NO MATERIAL FINDING. You may not approve the merge. End with the single check a human should still run. <contract> [paste] </contract> <diff> [paste] </diff>
Tips that keep the review yours
- Paste the contract above the diff so Claude is not grading the code against a guess.
- Cap the list at five findings. A longer list usually mixes style with risk.
- Use OBSERVED, INFERRED, and QUESTION so a missing file cannot become a fake bug.
- Run security in its own prompt. Do not ask for a rewrite in that pass.
- Ask for a failing test before you ask for a fix.
- Strip secrets and production data before the prompt leaves your machine.
- Post review comments yourself after you reproduce the finding.
- A result of no material finding is a checklist, not an approval.
Primary sources
Checked September 26, 2026. Anthropic's announcement describes multi-agent pull-request review, inline comments, and human approval. Plan access and price change, so confirm them in your workspace before you quote a cost.
Claude code review FAQ
What is a good Claude prompt for code review?
Give Claude the intended behavior, the diff, and the tests that already exist. Ask for a short list of findings with a file reference, the evidence in the diff, a failure scenario, and whether the claim is observed or inferred. Tell it to return no material finding when a category is clean. A prompt that only says review this code produces style notes and invented context.
Can Claude approve a pull request?
No. Claude can draft findings and comments. A person who owns the change decides whether to merge. Anthropic's Code Review documentation describes inline comments on GitHub pull requests and still treats approval as a human decision. Availability and billing depend on your plan and workspace, so check the product you actually have before you rely on an automatic review.
Should I paste the whole repository?
Start with the diff and the interfaces it calls. Name files Claude cannot see. A full repository dump adds noise and can include secrets, tokens, or personal data. If a finding depends on a file you did not paste, the prompt should label it as a question, not a defect.
How is this different from a Claude coding guide?
Coding guides help you implement a change. This page is only for reviewing a change that already exists. The step-by-step review workflow, including what to verify before merge, is on the Claude code-review how-to. Use these prompts when you are ready to paste a diff.
Can I use these prompts in Claude Code?
Yes, as the review brief. Claude Code documents a /code-review command and a GitHub review that can post comments. The prompts also work in a normal Claude chat if you paste the diff yourself. Do not put live secrets in the prompt. Run the tests the finding names before you change production code.
How do I stop Claude from inventing a bug?
Require a file and line, a quote from the diff, and a concrete input that fails. Ask it to separate observed facts from inferences. If it cannot point at the diff, it should write QUESTION, not BUG. Then open the lines yourself.
Should security and style be in the same prompt?
No. A style pass hides authorization, injection, and data-exposure findings. Run the security prompt on its own after the correctness pass. Treat the result as triage. It is not a security certification, and high-impact systems still need a qualified reviewer.
What should I ask after I fix a finding?
Paste the new diff and the regression test. Ask whether the original failure is addressed, whether a new edge case appeared, and whether another invariant got weaker. Then run the test. Do not ask for a fresh open-ended review of the whole repository.