AI code review prompt for Claude Code, Cursor, and Copilot

A useful AI code review prompt asks for findings you can disprove: a location, a triggering input, an expected result, and a test that fails today. Without that shape, a model tends to return style advice and confident summaries that are hard to check.

Paste this prompt into any chat model, replace the intent line, and paste the diff at the end. It works for a patch written by a person or by an agent.

Review the diff below as a skeptical senior engineer. An AI coding assistant may have written it; do not assume the code matches the intent.

Intent: <what this change must do, and what it must not change>

Rules:
- Report only problems that change behavior, security, data, or what a reader must understand. Skip style issues a formatter or linter would catch.
- Make every finding falsifiable. Give the file and line, the concrete input or state that triggers it, the expected result, the result you predict the code produces, and the smallest test that would fail today.
- If you cannot name a triggering input, label the item "question", not "bug".
- Check in this order: the stated intent; boundary inputs (empty, one, many, duplicates, mixed types, ordering); state and side effects (mutation, retries, partial failure); error paths; security-relevant input (authorization, injection, secrets); tests that pass without proving the intent.
- Write "not traced" for anything you did not follow through the code. Do not claim that you ran code or tests.
- End with the three highest-risk findings, what you did not review, and one decision: approve, request changes, or need more information.

Diff:
<paste the diff>

The intent line matters most. A reviewer, human or model, cannot tell that code is wrong without knowing what it was supposed to do. One or two sentences about what must change and what must stay the same are enough.

The prompt is free to copy. It does not make the reviewer correct; the rest of this guide shows how to install it in your tools and how to check what it reports.

• Behavior over style: formatters and linters already catch formatting. Review attention is limited, so the prompt spends it on outcomes.
• Falsifiable findings: a named input and predicted output can be tested in a minute. A vague concern such as “consider edge cases” cannot.
• Question versus bug: the label keeps speculation visible as speculation, so you do not spend time disproving a guess presented as a defect.
• A fixed checking order: starting from intent and boundaries mirrors the AI code review checklist. It reduces the chance that the review stops after the first plausible issue.
• “Not traced” and no claimed runs: a chat model reviewing pasted text has not executed anything. Asking it to say what it skipped makes the coverage of the review explicit.
• A decision at the end: approve, request changes, or need more information. A review without a decision is commentary.

In Claude Code, a project skill turns the prompt into a slash command. Save this as .claude/skills/review-diff/SKILL.md and run /review-diff followed by one sentence describing the intent.

---
name: review-diff
description: Skeptical review of the uncommitted diff with falsifiable findings
argument-hint: [intent of the change]
disable-model-invocation: true
allowed-tools: Bash(git diff *)
---

Review the diff below as a skeptical senior engineer. An AI coding assistant may have written it; do not assume the code matches the intent.

Intent: $ARGUMENTS

Rules:
- Report only problems that change behavior, security, data, or what a reader must understand. Skip style issues a formatter or linter would catch.
- Make every finding falsifiable. Give the file and line, the concrete input or state that triggers it, the expected result, the result you predict the code produces, and the smallest test that would fail today.
- If you cannot name a triggering input, label the item "question", not "bug".
- Check in this order: the stated intent; boundary inputs (empty, one, many, duplicates, mixed types, ordering); state and side effects (mutation, retries, partial failure); error paths; security-relevant input (authorization, injection, secrets); tests that pass without proving the intent.
- Write "not traced" for anything you did not follow through the code. Do not claim that you ran code or tests.
- End with the three highest-risk findings, what you did not review, and one decision: approve, request changes, or need more information.

Diff:
!`git diff HEAD`

The !`git diff HEAD` line runs before the prompt reaches the model, so the current uncommitted diff against the last commit is inserted automatically. allowed-tools pre-approves that one command, and disable-model-invocation keeps the review from starting unless you ask for it. $ARGUMENTS receives the intent you type after the command.

For a branch instead of uncommitted work, change the command to compare against your base branch, for example git diff main...HEAD, and update allowed-tools to match. An older .claude/commands/review-diff.md file also works, but skills are the documented format for new commands.

In Cursor, save this as .cursor/rules/ai-review.mdc. With alwaysApply: false and no description or globs, it is a manual rule: it applies only when you mention @ai-review in a chat together with the diff or files to review.

---
alwaysApply: false
---

When asked to review, review the referenced diff or files as a skeptical senior engineer. An AI coding assistant may have written them; do not assume the code matches the intent. Ask for the intent if it is missing.

Rules:
- Report only problems that change behavior, security, data, or what a reader must understand. Skip style issues a formatter or linter would catch.
- Make every finding falsifiable. Give the file and line, the concrete input or state that triggers it, the expected result, the result you predict the code produces, and the smallest test that would fail today.
- If you cannot name a triggering input, label the item "question", not "bug".
- Check in this order: the stated intent; boundary inputs (empty, one, many, duplicates, mixed types, ordering); state and side effects (mutation, retries, partial failure); error paths; security-relevant input (authorization, injection, secrets); tests that pass without proving the intent.
- Write "not traced" for anything you did not follow through the code. Do not claim that you ran code or tests.
- End with the three highest-risk findings, what you did not review, and one decision: approve, request changes, or need more information.

For GitHub Copilot code review, save this as .github/instructions/code-review.instructions.md. The excludeAgent line keeps the Copilot cloud agent from reading these review instructions, so they apply to pull request review only.

---
applyTo: "**"
excludeAgent: "cloud-agent"
---

When reviewing a pull request, compare the diff with the pull request description and treat the description as the intent.

Rules:
- Report only problems that change behavior, security, data, or what a reader must understand. Skip style issues a formatter or linter would catch.
- Make every finding falsifiable. Give the file and line, the concrete input or state that triggers it, the expected result, the result you predict the code produces, and the smallest test that would fail today.
- If you cannot name a triggering input, label the item "question", not "bug".
- Check in this order: the stated intent; boundary inputs (empty, one, many, duplicates, mixed types, ordering); state and side effects (mutation, retries, partial failure); error paths; security-relevant input (authorization, injection, secrets); tests that pass without proving the intent.
- Write "not traced" for anything you did not follow through the code. Do not claim that you ran code or tests.
- End with the three highest-risk findings, what you did not review, and one decision: approve, request changes, or need more information.

Copilot code review reads instructions from the pull request's head branch, so the file must exist on the branch being reviewed. Repository-wide .github/copilot-instructions.md also works if you want the same rules for every Copilot feature.

Here is a small synthetic patch. The helper must return the three highest scores, highest first, without reordering the caller's array. A finding in the shape the prompt requests looks like the note below. It is an illustrative example, not a recorded model response.

bug: leaderboard.mjs:6
Trigger: scores with different digit lengths, e.g. [9, 100, 25, 3]
Expected: [100, 25, 9]
Predicted: [9, 3, 25], because sort() without a comparator compares strings
Failing test: assert.deepEqual(topScores([9, 100, 25, 3]), [100, 25, 9])

Do not accept or reject that finding on reading alone. Save the example as leaderboard.test.mjs and run node --test leaderboard.test.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';

// Plausible AI-generated helper under review.
function topScores(scores, limit = 3) {
  return [...scores].sort().reverse().slice(0, limit);
}

test('returns the highest scores first', () => {
  assert.deepEqual(topScores([40, 75, 62, 18]), [75, 62, 40]);
});

test('orders scores numerically across digit lengths', () => {
  assert.deepEqual(topScores([9, 100, 25, 3]), [100, 25, 9]);
});

test('does not reorder the caller\'s array', () => {
  const scores = [9, 100, 25];
  topScores(scores);
  assert.deepEqual(scores, [9, 100, 25]);
});

Two tests pass and one fails. The digit-length test reports actual [9, 3, 25] against expected [100, 25, 9]. The first test passes because every score has two digits, so string order and numeric order agree. A suite made only of cases like that one would not reveal the defect. The copy in [...scores] is correct, so the mutation test also passes.

Replace only the helper with this version and rerun the same command:

function topScores(scores, limit = 3) {
  return [...scores].sort((a, b) => b - a).slice(0, limit);
}

All three tests pass. To confirm the test has value, temporarily restore the original .sort().reverse() and check that the digit-length test fails again. The example uses only Node.js built-ins and was run with a current Node.js release on October 20, 2026; no install or account is needed.

A model reviewing a diff sees the text you paste. It usually does not see the callers, the data that reaches the code in production, the configuration, or the reason a strange-looking line exists. When it reviews a change it also wrote, it can repeat the assumption that produced the bug.

• Treat a finding as a hypothesis until a test, a trace, or a reading of the actual caller confirms it.
• Treat silence as missing evidence, not approval. A review that reports nothing has still not shown that the intent holds.
• Check the boundary yourself for authorization, money, data deletion, and anything irreversible, even if the review is clean.
• Keep the review note in the pull request: findings confirmed, findings rejected and why, and what nobody traced.

For the testing side of that note, the guide to testing AI-generated code shows how to derive cases from the contract, and mutation testing checks that a generated test can fail. Tool formats were checked against the Claude Code skills documentation, Cursor rules documentation, and GitHub Copilot repository instructions on October 20, 2026. Tools change; confirm the current format if a file is ignored.

The prompt narrows where to look. Deciding whether a finding is real, writing the failing test, and making the merge call are still review skills, and they weaken when every review is delegated.

ManualMode's free code review exercise gives you two synthetic AI-generated patches to approve or reject, with no account or code upload. It does not review your pull requests. Three Gym reps and one Project rep are free after signup, and a Project rep can be a bounded review or fix from your own repository, with raw source staying local by default.