Below are seven copy-ready code review prompts for Claude, ChatGPT and Codex: a careful senior review, a security review, a performance review, test gaps, a readability pass, a pull request summary and a self-review before you push. Paste your diff into any of them.
How to use these prompts
Each prompt below is ready to copy. Replace the blanks in double braces with your own text, or keep the default after the colon. Paste the diff where it says {{diff}}; for most reviews, the output of git diff or a pull request's changes is enough.
Two habits make any review prompt better. First, give the model the surrounding code it needs, not just the changed lines: a renamed argument means nothing without its callers. Second, ask for a fixed output shape. "For each issue give the file, the line, why it matters and the smallest fix" turns a vague essay into a list you can act on.
1. Careful senior review
The everyday review. It asks for real problems only and skips the noise.
Review the diff below as a senior {{language:TypeScript}} engineer.
Focus on {{focus:bugs, edge cases and security}}. For each issue give the
file, the line, why it matters and the smallest fix. Skip style nits that a
linter or formatter would catch. If the change looks good, say so in one line.
{{diff}}
2. Security review
Use it on anything that touches input, auth, files, money or secrets.
Review this diff for security problems only. Check for: injection (SQL,
shell, HTML), missing auth or permission checks, secrets in code or logs,
unsafe file paths, unvalidated redirects, and data exposed to the wrong user.
For each finding: severity (high, medium, low), file and line, how it could be
exploited in one sentence, and the fix. Do not list theoretical issues that the
surrounding code already prevents.
{{diff}}
3. Performance review
For hot paths, data-heavy screens and anything that runs per request. Telling the model your scale keeps it from flagging micro-optimizations that will never matter.
Review this {{language:TypeScript}} change for performance. Look for repeated
work inside loops, queries or network calls that could be batched, missing
indexes implied by new queries, and large objects copied or re-rendered
without need.
Only flag problems that matter at {{scale:about 10,000 users}}. For each one,
estimate the impact and give the simplest fix.
{{diff}}
4. Test gaps
Paste the change and the tests together. Models are good at spotting behavior that changed without a test changing with it, and at writing the first draft of the missing tests in your existing style.
Here is a change and its tests. List the behaviors the change introduces that
no test covers, starting with the ones most likely to break. For the top three,
write the missing tests in {{test_framework:the project's existing style}}.
Change:
{{diff}}
Tests:
{{tests}}
5. Readability pass
Use it on code you wrote in a hurry, or before handing a module to someone else. It works on whole files as well as diffs.
Review this code for readability, as if a new teammate has to change it next
week. Point out unclear names, functions doing more than one thing, comments
that explain what instead of why, and logic that could be simpler. Suggest
renames and small rewrites; do not change behavior.
{{code}}
6. Pull request summary
A good description gets a faster review. This one is written for the person reviewing, not the person who wrote the code.
Write a pull request description for this diff. Sections: What changed (bullet
points), Why (one or two sentences), How to test (numbered steps), and Risks.
Keep it under 200 words and write for a reviewer who hasn't seen the ticket.
{{diff}}
7. Self-review before you push
The cheapest review is the one you run before anyone else sees the change. Asking the model to play the strict reviewer catches the embarrassing things first.
I'm about to push this change. Act as the reviewer who will block it. List
anything that would get it sent back: leftover debug code, unhandled errors,
missing edge cases, TODOs, inconsistent naming, or changes unrelated to the
goal of "{{goal}}". Be brief and specific.
{{diff}}
Make your favorite one a skill
If you run the same review on every pull request, stop pasting it. Turn the prompt into a skill, and Claude Code or Codex will use it on its own whenever you ask for a review. Paste prompt 1 into the SKILL.md generator and it becomes a valid SKILL.md, with each blank turned into an instruction like "If the language isn't given, use 'TypeScript'."
To keep prompts like these one keystroke away, save them in Kipt: paste to save, press ⌘K to find one, and Enter copies it, with a small form for the blanks. Your library lives in your own GitHub repo, and the prompts you promote to skills install with one command.