Stop asking AI to "review this PR" — use a risk map instead

If you paste a pull request into ChatGPT, Claude, Cursor, or Copilot Chat and say “review this,” you usually get:

• a summary of what the diff already shows
• a handful of style opinions
• a generic reminder about “validating inputs”
• a friendly “looks good overall”

That is not a review. That is a book report.

After enough of those, people either stop using AI for review or — worse — start treating the essay as approval.

What actually goes wrong

No intent. Without one sentence on why the change exists, the model cannot tell a deliberate behaviour change from a bug.

No priority. Naming nits compete with authz bugs for the same paragraph budget.

No output contract. Free-form prose hides severity. You want Must fix / Should fix / Nit, locations, and a verdict.

Equal time for unequal risk. Renames and payment-path changes should not get the same depth.

A better default loop

Use four steps:

1. Diff + intent — skim --stat, write one sentence of purpose.
2. Risk map — ask the model only which areas deserve depth (auth, money, migrations, public API, supply chain, hot paths).
3. Deep dives — new prompts (or new turns) on those areas: security, tests, API breaks, migrations, etc.
4. Human verdict — dedupe, drop wrong nits, you own merge.

The important part is splitting map from deep dive. One mega-prompt on a 3k-line PR burns context and produces shallow commentary.

A skeleton that works across tools

You can adapt this in Cursor, Claude Code, ChatGPT, or Copilot Chat:

You are a senior engineer doing a pre-merge review. Do not edit files.

## Context
- Intent: <one sentence>
- Diffstat: <paste>
- Risk notes: <auth? migration? public API?>

## Process
1. Risk map (area → why → files)
2. Correctness vs intent
3. Security (authz, injection, secrets)
4. Tests (new behaviour covered? tests weakened?)
5. Only then maintainability that hides real risk

## Output
### Risk map
### Findings (Must fix / Should fix / Nit, with path:line, why, fix)
### Verdict: Approve | Approve with nits | Request changes
### Open questions

Do not invent issues. If nothing serious, say so.

Keep the output contract. It is doing more work than the adjectives in the role line.

Specialist passes beat one giant checklist

Once you have a risk map, fan out:

• Trust boundary → security threat model + Pass/Fail evidence
• Behaviour change → behaviour↔test matrix (watch for deleted or loosened tests)
• Schema → expand/contract and lock risk
• Manifest/lockfile → necessity and install scripts, not only audit noise

You rarely need every pass. Two deep dives on the real risks beat eight shallow ones.

Team norms that keep this healthy

• Human owns merge. The model is a junior reviewer, not a gate bot.
• Shared severity words. Must fix means blocks merge.
• Read-only review chats. Implement fixes in a separate turn so “findings” do not silently become a rewrite.
• Authors can paste a risk map into the PR to save reviewers’ discovery time — without requiring them to accept every nit.

Privacy reminder

If your company forbids pasting code into a given tool, these prompts do not override that. Use whatever surface policy allows (including self-hosted options).

Soft close

I’ve been packaging this loop as a small set of copy-paste prompts and checklists (full PR, security, performance, tests, API, migrations, frontend a11y, dependencies) for people who already live in AI coding tools and just want reviews that surface real risk.

If you try the risk-map-first skeleton above on your next non-trivial PR, watch whether the Must-fix list gets shorter and more serious. That feedback loop matters more than any tool brand.

— Pluto · @Mars_Peakul