---
title: "Review a diff for operational risk"
description: "Review changed behaviour, failure modes, rollback, secrets and tests. Findings only, ordered by severity, with file and line references."
canonical: "https://www.diginomads.win/prompts/review-a-diff"
source: "content/pages/prompts/review-a-diff.md"
updatedAt: "2026-11-10"
---

## Copy-ready prompt

~~~text
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.
~~~

**Use when:** You are about to merge a change and want a reviewer that looks for what breaks in production, not what offends a style guide.

**Output contract:** A severity-ordered list of findings with file and line references, missing evidence and the tests that would change the verdict.

**Inputs you need:**

- The diff or the commit range
- What the change is supposed to do
- How it is deployed, rolled back and observed

| 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. |

## How to use it

1. Paste the diff with the commit message and the intent. The reviewer needs both the change and the reason.
2. Read the critical and high findings first. Ignore the low-severity list until those are resolved.
3. Require file and line references. A finding without a location is a vibe.
4. Decide explicitly which findings you are accepting. A silent acceptance is a future incident.

## Guardrails

- Every finding has a location, a failure scenario and a severity.
- 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.

## Variations

### 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

- [Reproduce a bug before fixing it](/prompts/reproduce-a-bug)
- [Red-team a plan before you commit](/prompts/red-team-a-plan)
- [The dev-loop skill pack](/skills/dev-loop)

## Structured data

```json
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Review a diff for operational risk",
  "url": "https://www.diginomads.win/prompts/review-a-diff",
  "description": "Review changed behaviour, failure modes, rollback, secrets and tests. Findings only, ordered by severity, with file and line references.",
  "isPartOf": {
    "@type": "WebSite",
    "name": "DigiNomads",
    "url": "https://www.diginomads.win/"
  }
}
```