The worst part of a code review is not reading the code. It is the moment you have to write a comment that is clear, specific, and still kind, while a bug hides three lines above where you are looking. Vague notes like “can you clean this up?” help no one, and missed edge cases ship anyway. The six ChatGPT prompts below help you review a diff with a checklist, find the real problems, and phrase every comment so the author can act on it.
Step 1 — Prepare the review before you read the diff
1. Build a checklist for this kind of change
You are a senior engineer. I am reviewing a [type of change] in [language]. Give me a review checklist of 8 items that matter most for this kind of change, ordered from highest to lowest risk. Keep each item to one short line.What it does: Gives you a focused checklist so you do not skim past the parts of a change that carry the most risk.
How to use: replace [type of change] and [language]; keep the rest as is.
2. Summarize what the diff does
Here is a code diff: [paste diff]. In five bullet points, explain what this change does, what it touches, and what a reviewer should look at first. If the diff changes existing behavior, call that out explicitly.What it does: Gives you a fast, neutral summary of the change before you judge the details.
How to use: paste the diff into [paste diff]; keep the rest as is.
3. Flag behavior the diff does not handle
For this code: [code], list the inputs and states it does not handle, such as empty values, nulls, large numbers, or concurrent access. Order them by how likely they are to occur in production, and give a one-line example for the top three.What it does: Surfaces the edge cases a diff quietly forgets before they reach users.
How to use: paste the changed code into [code]; keep the rest as is.
Step 2 — Write comments the author can act on
4. Hunt for bugs and risky logic
Review this [language] code for correctness: [code]. Point out bugs, off-by-one errors, unclear control flow, and any place the code does something different from what the names suggest. For each finding, cite the line, explain the risk in one sentence, and suggest a fix.What it does: Produces specific, line-level findings instead of a general “looks fine.”
How to use: replace [language] and paste your code into [code]; keep the rest as is.
5. Check for security and data issues
Review this code for security and data-handling problems: [code]. It runs in [framework or runtime]. Look for untrusted input, unsafe queries, leaked secrets, and missing validation. List each issue with a severity of high, medium, or low, and one concrete fix per issue.What it does: Adds a security pass to a normal review without needing a separate tool.
How to use: paste your code into [code] and set [framework or runtime]; keep the rest as is.
6. Rewrite a harsh comment
Rewrite this review comment so it is specific, kind, and easy to act on: [your comment]. Keep the same technical point, name the exact place it applies, and suggest the change rather than just pointing out the problem. Give me two versions: one short and one detailed.What it does: Turns a blunt note into feedback that helps the author without bruising them.
How to use: paste your draft comment into [your comment]; keep the rest as is.
Common mistakes
- Reviewing style before substance. Formatting nits drown out the one comment that actually matters.
- Leaving comments without a location. “This could be simpler” with no line reference forces a guessing game.
- Approving a large diff after one pass. Big changes need a second read focused only on edge cases.
Every prompt on GuPrompt is free to copy — no signup, no paywall.
Keep going
- Browse the full Coding prompt collection.
- Building UI after the review passes? See Claude prompts for React components.
- Chasing a live issue instead? Try ChatGPT prompts for debugging.
- Planning what to build next? Read ChatGPT prompts for keyword research.