Awesome Claude Prompts Unofficial

Code review prompt

Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.

Task: Code review prompt · Other tasks

Fill in the details

A unified diff works best because it shows file names and what changed. Remove secrets such as keys or passwords before pasting.

Optional, but it lets Claude check the change against its purpose instead of only its style.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • You have a diff or a small set of changed files and want a second look before you merge or ask a colleague to review.
  • You want the review aimed at one concern, such as security or edge cases, rather than a general list of comments.
  • You are reviewing someone else's change and want help spotting problems you can then verify yourself.

When not to use it

  • The change spans many files that depend on code you cannot paste. Claude will only see the diff, so it cannot judge effects outside it.
  • You need a style or lint check. A formatter or linter does that faster and more reliably than a prompt.
  • The code contains secrets or material you are not allowed to share. Remove or replace them before pasting anything.

Why this structure

  • The diff comes first, inside <diff> tags, which helps Claude tell the code apart from your instructions and from the optional context lines below it.
  • The optional intent block appears only when you fill it in. When present, it lets Claude check whether the change does what it is meant to do, which a diff alone cannot show.
  • Each finding is requested in four parts (location, problem, impact and fix), so you can check the evidence and judge the suggested change.
  • Findings are ordered by severity and labelled "Must fix" or "Worth considering", which makes important problems easier to spot among small suggestions.
  • The last paragraph asks Claude to report only what the code supports and to say what context is missing. It also gives Claude explicit permission to report that there are no real problems, which discourages padding the review.

Example input (fictional)

Diff or code change
--- a/billing/invoice.py
+++ b/billing/invoice.py
@@ -10,7 +10,7 @@ def total(lines):
-    return sum(l.price * l.qty for l in lines)
+    return sum(l.price for l in lines) * len(lines)
What the change is supposed to do
Simplify the invoice total calculation.
Language or framework
Python
Review focus
Correctness and edge cases

Follow-ups to send Claude

  • For the first "Must fix" item, write the corrected code and a unit test that would have caught the problem.
  • Which of your findings depend on assumptions about code that is not in the diff? List the assumption for each.
  • Explain the most severe issue as a short comment I can paste into the pull request.

Common mistakes

  • Pasting a whole file when only a few lines changed. The review then spreads across code you did not touch. Paste the diff, or mark which lines changed.
  • Leaving out what the change is for. Without intent, Claude can only judge how the code is written, not whether it does the right thing.
  • Accepting a finding without checking it. Treat each item as a lead to verify against the real codebase, especially anything about code outside the diff.
  • Debug an error: Turn an error message and the code around it into a ranked list of likely causes, a check for each, and a fix you can try.
  • Write unit tests: Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.

See all templates

Sources