This is a "wrong-shaped output" failure, not a discipline failure. The reviewer complies (it produces a report) but the report has the wrong shape — verdicts buried under narration. Per **Match the Form to the Failure**, the right form is a **positive recipe/contract** that states what the output IS, in order. A prohibition ("don't narrate your process") would backfire — under the competing incentive to be thorough, it measurably produces more narration than no guidance at all.

But first, the Iron Law: **no skill (or guidance edit) without a failing test first.** I have not yet watched the current template fail, nor confirmed the recipe wording beats a no-guidance control. So below I give the candidate text I would test, but it is not yet deployable. The verification plan is the actual work.

## (1) Exact text I would add to the template

```markdown
## Report format

Your report IS these sections, in this exact order. Produce them and nothing before them:

1. **Verdict** — one line: `PASS`, `FAIL`, or `BLOCKED`.
2. **Blocking issues** — bulleted list of issues that justify a FAIL/BLOCKED,
   each one line: `<location>: <what is wrong>`. Write `None` if there are none.
3. **Non-blocking notes** — optional bulleted list of suggestions that do not
   affect the verdict. Write `None` if there are none.
4. **Evidence** — for each blocking issue, the specific file/line and the
   reason it fails. This is where detail belongs.

The first line of your report is the verdict. Nothing precedes it.
```

Notes on form choices:
- It's a **contract/recipe**: states the parts and their order, leaving nothing to negotiate.
- **No prohibition on narration.** Instead, narration has nowhere to go — there is no slot for "first I read the diff." Detail is given a home (Evidence) so the model isn't fighting the urge to show its work.
- **Verdict is a REQUIRED structural slot in position 1**, not a prose reminder ("remember to lead with the verdict").
- **No nuance/exemption clauses** ("unless the diff is large…"). A real exception would become its own conditional on an observable predicate.

## (2) Verification plan before deploying

**RED — baseline (mandatory, do this first):**
1. Take 5+ real diffs of varying outcomes (some PASS, some FAIL, some BLOCKED).
2. Run the **current** template (no edit) on each. Confirm the failure actually reproduces: verdicts buried under narration. If it doesn't reproduce, stop — there's nothing to fix.
3. Record verbatim where the verdict lands and how much narration precedes it.

**Micro-test the wording (cheap, before full scenarios):**
4. One API call per sample. System prompt = the **full reviewer template with the candidate text inserted** (realistic context, not the snippet in isolation). User message = a diff that tempts narration.
5. Always include the **no-guidance control** (current template) head-to-head.
6. 5+ reps per variant. Single samples lie.
7. **Read every report manually** — automated "verdict appears in line 1" checks get fooled by quoted examples and template echoes.
8. Score: (a) verdict on first line, (b) zero process narration before it, (c) blocking issues separated from notes.
9. **Variance is a metric.** If the 5 reps under the recipe converge on the same shape, the contract is binding. If they diverge (five interpretations), tighten the form before adding words — do not pile on prose.

**Guard against the prohibition trap:**
10. Optionally run a third variant that *adds a prohibition* ("do not narrate your process") to confirm it scores worse than the recipe — this validates the form choice and documents why we didn't use it.

**GREEN / REFACTOR:**
11. If the recipe wins decisively across reps, deploy. If narration leaks into the Evidence section, that's a new shaping leak — restructure (e.g., constrain Evidence to `file:line — reason` bullets) rather than adding "be concise" prose.
12. Commit only after the manual read of all reps confirms compliance.

I would not deploy the text in (1) until steps 1–9 pass.