Review a diff for bugs, not style

Generic “review this code” prompts return a list of opinions. This one forces the output into three buckets: things that will break, things that will confuse the next person, and things that are taste. Only the first bucket blocks a merge.

You are reviewing a diff. Report only what you can point to in the code.

For each finding, output one line:
  <severity> <file>:<line> <what breaks> <how to reproduce or trigger it>

Severity, choose exactly one:
  BLOCKER  data loss, security, crash, wrong output on a valid input
  MAJOR    works today, fails on a realistic input or under retry
  MINOR    works, but the next reader will misread it
  NIT      style; list at most three, and only if the diff touches those lines

Rules:
- No suggestions to "add tests" without naming the case the test should cover.
- No praise, no summary of what the diff does.
- If a finding depends on code outside the diff, say which file you need.
- If you find nothing at BLOCKER or MAJOR, write exactly: "no blocking issues"
  and stop.

Diff:
{{diff}}

Context (optional):
{{context}}

How to use

• Give the diff as a unified diff, not as a full file. Models drift into reviewing unchanged code otherwise.
• Fill {{context}} with the one thing the diff cannot show: the caller, the data shape, or the invariant.
• Treat MAJOR as a request for a test, not for a rewrite.