Code review prompts for Claude Code, Codex and ChatGPT

A general-purpose code review prompt

Start with this one. It works on any diff, in any tool, and the variants below reuse its output format so findings from different passes read the same way.

Review the code change below before it merges.

Report only problems this change introduces or makes worse:
bugs, security holes, data loss, crashes, broken error handling,
and clear performance regressions.

Scope
- Review the diff. Read surrounding code only to confirm a finding.
- Skip formatting, naming and style that a linter or formatter catches.
- Skip problems that existed before this change, unless it makes them worse.

For each finding, give
- Severity: Critical, High, Medium or Low
- Location: file path and line number
- Problem: what goes wrong, and the input or sequence that triggers it
- Evidence: the lines of code that show it
- Fix: the smallest change that resolves it

Rules
- Report a finding only if you can point to the code that causes it.
  If you would need to check something first, say what, or leave it out.
- Order findings from most to least severe.
- If nothing meets this bar, reply with exactly "No findings."
  Don't add minor comments to fill the review.

<diff>
PASTE THE DIFF HERE
</diff>

The diff sits inside <diff> tags so the model can tell instructions from code, which matters when the diff itself contains comments or strings that read like instructions.

Code review prompts for focused passes

A single prompt that asks for everything tends to spread its attention thin. For changes that touch authentication, data access or a busy endpoint, run a focused pass as well. Each prompt below goes above the same <diff> block.

Security review prompt

Do a security review of the diff below. Look only for
vulnerabilities this change introduces:

- Input from users, files or the network reaching SQL, shell commands,
  file paths, HTML or templates without validation or escaping
- New endpoints, jobs or queries that skip authentication or
  authorization, or that return another user's or tenant's data
- Secrets, tokens or personal data written to code, logs or error messages
- Hand-rolled cryptography, weak randomness for tokens, disabled
  certificate checks
- New dependencies, and what they are given access to

For each finding: severity, file and line, how an attacker would reach
it, and the fix. Rate severity by what an attacker could actually do,
not by the category name. If you find nothing exploitable, reply
"No findings."

Performance review prompt

Review the diff below for performance problems only.

Flag:
- Queries or network calls inside loops (N+1)
- Work that grows with input size where it didn't before: nested loops
  over collections, repeated scans, unbounded lists loaded into memory
- Missing pagination or limits on queries that can return many rows
- Expensive work added to a hot path: per request, per render,
  per message
- Caches that never expire, or that are keyed so they never hit

For each finding: file and line, the input size or traffic at which it
starts to hurt, and a cheaper approach. Don't flag micro-optimizations
the runtime or compiler already handles. If nothing qualifies, reply
"No findings."

Test coverage prompt

Review the tests in the diff below against the code it changes.

1. List each behavior the change adds or modifies.
2. For each one, name the test that covers it, or say "not covered".
3. Point out tests that would still pass if the code were wrong:
   assertions on mocks only, snapshots nobody reads, missing
   assertions, or tests that never reach the changed branch.
4. List the edge cases worth a test: empty input, limits, errors
   from dependencies, concurrent calls, time zones.

Write test names and one-line descriptions, not full test code.
If coverage is adequate, say so in one sentence.

Pull request prompt: review only the diff

For a pull request, give the model the author’s stated intent as well as the diff. A review that compares the two catches changes the description never mentions, which is where unintended edits hide.

You are reviewing pull request #<NUMBER>: "<TITLE>".
The author says it does this: <ONE-LINE SUMMARY FROM THE PR DESCRIPTION>

Review only the lines this pull request changes, shown below as a diff
against the base branch. Use unchanged code for context, but don't
report issues in it.

First, in one or two sentences: does the diff do what the description
says? Point out anything it does that the description doesn't mention.

Then list findings with severity (Critical, High, Medium, Low), file
and line, the problem, and a suggested fix. Only report problems you
can tie to a changed line. If there are none, reply "No findings."

<diff>
PASTE THE OUTPUT OF: git diff main...HEAD
</diff>

Prompt for reviewing AI-agent-written code

Code from a coding agent fails in its own ways: it calls functions that don’t exist, adjusts tests until they pass and quietly catches errors. This prompt points the review at those patterns. The code review checklist has the same questions for a human reviewer.

The diff below was written by a coding agent. Review it as you would a
new teammate's first pull request, and look in particular for:

- Code that assumes an API, function, option or config key exists:
  check that each one it calls is defined in this repository or in a
  dependency at the installed version
- Tests changed to match the new behavior instead of the requirement:
  weakened assertions, deleted cases, new skips
- Errors swallowed so the code "works": empty catch blocks, broad
  fallbacks, default values that hide failures
- Duplicates of helpers that already exist elsewhere in the repository
- Changes outside the task: unrelated files, reformatting, renamed
  public functions
- TODOs, placeholders or hard-coded values left in place of real logic

For each finding: severity, file and line, evidence, fix. If the change
is sound, reply "No findings."

How to run a Claude code review prompt as a slash command

In Claude Code, a prompt you reuse becomes a slash command. Save it as .claude/commands/review-diff.md and /review-diff runs it. Claude Code has merged custom commands into skills: a skill at .claude/skills/review-diff/SKILL.md creates the same command, and adds a folder for supporting files and the option for Claude to load it on its own when a task matches its description. Existing files in .claude/commands/ keep working.

---
description: Review this branch against main for bugs and security issues
argument-hint: [extra focus, optional]
allowed-tools: Bash(git diff *)
---

## Changed files
!`git diff --stat main...HEAD`

## Diff
!`git diff main...HEAD`

## Instructions
Review the diff above. Report only problems this change introduces:
bugs, security holes, data loss, crashes, performance regressions.
Skip anything a linter or formatter would catch.

For each finding: severity (Critical, High, Medium, Low), file and
line, the problem, the evidence, and the smallest fix.
If nothing qualifies, reply "No findings."

Extra focus for this review: $ARGUMENTS

• !`git diff main...HEAD` runs before the prompt is sent, and Claude receives the command’s output in its place. Claude Code checks each injected command against your permission rules, so allowed-tools: Bash(git diff *) pre-approves it.
• $ARGUMENTS receives whatever you type after the command, so /review-diff the retry logic in sync.ts adds a focus to a single run.
• Pick a name other than code-review. Claude Code ships a bundled /code-review skill, and a project skill with the same name replaces it. Our guide to the Claude Code review skill covers what the bundled one does.

Commit the file and everyone working in the repository gets the same command. A copy in ~/.claude/skills/ is yours alone and applies to every project on your machine; when both exist, the personal one wins.

How to run a code review prompt in Codex CLI

The quickest route is built in. Type /review in the Codex CLI, choose Custom review instructions, and paste a prompt from this page without the diff block, adding a line that says what to review, such as “the changes on this branch against main.” Codex reports findings without modifying your working tree. The Codex code review guide covers the other review presets and the GitHub integration.

For a prompt you run often, make it a skill. Codex reads skills from .agents/skills in every directory from where you work up to the repository root, and from $HOME/.agents/skills for your own. A skill’s SKILL.md needs a name and a description; call it by typing $ and its name, or pick it from /skills.

---
name: review-diff
description: Review the current branch against main for bugs and security issues. Use when asked to review a change, a branch or a pull request.
---

1. Run `git diff main...HEAD` and read the result.
2. Review only the changed lines. Report problems this change
   introduces: bugs, security holes, data loss, crashes,
   performance regressions. Skip style a linter would catch.
3. For each finding give severity (Critical, High, Medium, Low),
   file and line, the problem, the evidence, and the smallest fix.
4. If nothing qualifies, reply "No findings."

Older setups keep prompts in ~/.codex/prompts/ and run them as /prompts:name. OpenAI now marks custom prompts as deprecated in favor of skills, and because they live in your home directory they aren’t shared through the repository.

How to use a code review prompt in ChatGPT or Claude

Without an agent, produce the diff yourself and paste it under the prompt:

git diff main...HEAD > review.diff

The three dots matter. git diff main...HEAD shows what your branch changed since it left main, which is what a pull request contains. With two dots, anything merged into main since you branched appears as if you had reverted it, and the model reviews changes you never made.

Paste the file’s contents into the <diff> block, or attach it. A chat window sees only what you give it, so when a finding depends on code outside the diff, such as the function a changed line calls, paste that too, or tell the model to say what it would need to see instead of guessing.

What makes an AI code review prompt work

Every prompt above repeats five choices. They’re what separate a review from a list of opinions.

• Scope. Limit the review to the changed lines and to problems the change introduces. Otherwise the model reports old debt in surrounding code, and the real finding gets lost among them.
• Severity levels. Critical, High, Medium and Low let you read the top of the list and stop. They also make the model weigh each finding before writing it.
• Evidence and line references. A finding tied to a file, a line and the triggering input can be checked in a minute. One that can’t be tied to code is usually a guess.
• No style nits. Formatting, import order and naming conventions belong to the linter and formatter that already run in CI, where they’re enforced every time.
• A “No findings” answer. A model asked to find problems tends to find some. Naming the clean answer gives it permission to stop.

The biggest source of noise in AI code review is a prompt with no bar for what counts as a finding. Asking for a severity, a file and line, and the code that proves each problem, and accepting “No findings” for a clean diff, turns a review prompt from a request for opinions into a request for evidence that a reviewer can verify.

Where a review prompt stops being enough

A prompt only runs when someone remembers to run it, and it carries only what you put in it this time. Your team’s actual rules, such as “every query is scoped to the workspace” or “generated files are off limits,” get retyped, trimmed or forgotten from one review to the next.

Move the rules that hold on every change into files the repository keeps. AGENTS.md holds the conventions your coding agents follow, and a REVIEW.md holds guidance that matters only in review:

# Review guidance

## Always check
- Every API handler scopes queries to the caller's workspace.
- Money is stored as integer cents.

## Leave alone
- Formatting and import order (the formatter runs in CI).
- Generated files under src/gen/.

## Severity
- A missing workspace scope is always Critical.

With those files in place, the prompt shrinks to the part that changes per run, and the rules apply to every review, not only the ones someone started by hand. HeyDeer reads REVIEW.md and AGENTS.md, along with repository checks that each get a reviewer of their own.

An always-on reviewer removes the step of remembering. HeyDeer reviews every pull request on GitHub against the whole repository, verifies each finding against the code before posting it, and labels it Critical, High, Medium or Low, so the qualities a good prompt asks for are applied on every pull request without anyone pasting a diff.

Keep the prompts on this page for the moments a pull request doesn’t cover: a branch before you push, a focused security pass on one risky change, or a second opinion on code an agent just wrote.

Sources

1. Claude Code Docs: Extend Claude with skills (custom commands)
2. OpenAI Codex docs: Build skills
3. OpenAI Codex docs: Custom prompts
4. OpenAI Codex docs: Codex CLI
5. Git documentation: git diff