Every finding has a location, a failure scenario and a severity.
Coding
Review a diff for operational risk
Review changed behaviour, failure modes, rollback, secrets and tests. Findings only, ordered by severity, with file and line references.
Review this diff for operational risk. Do not rewrite the code.
Inputs:
- Diff: [DIFF]
- Intended behaviour: [INTENT]
- Deployment, rollback and observability: [OPS]
Work in this order:
1. Summarise the behaviour change in two sentences. If the diff and [INTENT] disagree, say so first.
2. Find issues in these categories, in this priority: data loss or corruption, security, availability, correctness, operability, tests.
3. For each finding, give: severity (critical/high/medium/low), file and line, the failure scenario, and the evidence in the diff. If you are inferring, say "inference".
4. Check what is missing: a migration, a rollback path, a metric, a log, a test, a feature flag, a timeout, a retry limit.
5. Ask for the specific evidence that would change your verdict.
6. End with the three findings to fix before merge and the one to accept with a follow-up.
Rules:
- No style nits unless they change behaviour or hide a bug.
- Do not assume a test exists because the file exists. Name the test and what it asserts.
- Do not propose a rewrite. Propose the smallest change that removes the risk.
- If the diff is too large to review, say so and propose the split.
| Variable | What to put there |
|---|---|
[DIFF] | The full diff, including deletions. A summary hides the removed check that mattered. |
[INTENT] | What the change is for, in one paragraph. Without it the review cannot tell a bug from a deliberate trade-off. |
[OPS] | How it ships: deploy process, rollback, feature flags, dashboards and the on-call path. |
Run it
How to use this template
Paste the diff with the commit message and the intent. The reviewer needs both the change and the reason.
Read the critical and high findings first. Ignore the low-severity list until those are resolved.
Require file and line references. A finding without a location is a vibe.
Decide explicitly which findings you are accepting. A silent acceptance is a future incident.
Checks
Guardrails before you trust the output
Missing tests, migrations and rollback paths are reported as findings.
Inferences are labelled as inferences.
The review does not propose a rewrite of unrelated code.
Adapt
Variations worth keeping
If the change is a database migration
Add: “Check forward and backward compatibility, lock duration, backfill plan and the exact rollback command. State what happens if the deploy stops halfway.”
If the change is a dependency upgrade
Add: “List the behaviour changes in the changelog that affect this repository, the tests that cover them and the rollback version.”
Why this works
Code review prompts often produce a list of style preferences. That is not the risk surface. The risk surface is data, security, availability and the operability of the change at 02:00 on a Sunday.
The prompt asks for a behaviour summary first. If the diff does not do what the author says it does, that is the most important finding, and it is easy to miss when you start line by line.
What good looks like
A good review is uncomfortable but short. Three findings that could page someone, not thirty that could be fixed by a formatter. Each finding names the scenario: “if the retry fires twice, the job writes two rows because the idempotency key is generated after the write”.
The “accept with a follow-up” line matters. It forces a decision instead of an indefinite maybe.
Adapt it to your work
For a client repository, add their deployment and rollback constraints to [OPS]. For an open-source review, add the supported versions and the compatibility promise. For an agent-generated diff, add “flag any change that is larger than the stated intent”.
Failure modes
- The review is a rewrite. Reject it and ask for the smallest change per finding.
- The severity is everything critical. Ask for the scenario and the blast radius; severity without a scenario is noise.
- The review misses deleted tests. Ask specifically what was removed and whether the coverage moved.
Related templates
This page is part of the free library.
The prompt is also in the Markdown mirror at
/prompts/review-a-diff.md. If the scenario is close but not right, send the gap to the help desk with the output you expected.
Found a gap in the library?
Send the scenario, the prompt that failed, or the harness change that broke your setup. The help desk takes questions and corrections from humans and agents, and every accepted fix updates the page date.