I'll work through this following my writing-skills training. Let me first classify the failure type, because that determines the form of the guidance.

## Classifying the failure

The reviewer **complies** with the task (it produces a review) but the **output has the wrong shape** — verdicts buried under process narration. This is a shaping failure, NOT a discipline failure.

Per "Match the Form to the Failure":

> **Complies, but output has the wrong shape (bloated prompt, buried verdict, restated spec)** → Right form: **positive recipe or contract: state what the output IS** — its parts, in order. Wrong form: **prohibition list ("don't narrate", "never restate")**.

So the instinct to write "Don't narrate your process" is exactly wrong here. Prohibitions measurably backfire on shaping problems — under the competing incentive ("show my work so the verdict is trustworthy"), the agent negotiates with "don't narrate" and produces *more* narration. I'll write a recipe that defines the output's parts in order, with the verdict first. There's nothing to negotiate: the output matches the shape or it doesn't.

I also need to avoid exemption/nuance clauses ("narrate only when necessary") — those reopen the negotiation.

---

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

```markdown
## Report format

Your report has exactly these parts, in this order. Fill each slot.

1. **Verdict** (first line): one of `APPROVE` / `REQUEST CHANGES` / `BLOCK`.
2. **Reason** (1–2 sentences): the single most important factor behind the verdict.
3. **Findings**: a list. Each finding is one row:
   `[severity] file:line — what is wrong — what to do`
   Severity is one of `blocker` / `major` / `minor` / `nit`.
   Order findings by severity, blockers first.
4. **Evidence** (optional, last): anything a controller would need to audit a
   specific finding — a quoted snippet, a reproduction, a reference.

The verdict and reason come before any finding. The controller reads the first
two lines and knows the outcome.
```

Notes on the design choices:
- **Recipe, not prohibition.** I never say "don't narrate." I define what each slot *is*. Process narration has no slot, so it has nowhere to go.
- **Verdict is a named first slot with an enum.** Structural placement (slot #1, first line) is what fixes an omitted/buried element, per the "omits a required element → REQUIRED slot in the template" row.
- **Evidence slot, last and optional.** The legitimate reason an agent narrates ("the controller needs to trust my finding") is real, so I give that content a *home* — an Evidence slot at the end — rather than exempting it. An exemption clause ("you may narrate when it supports a finding") wouldn't scope; it would leak narration back into the top. A dedicated terminal slot satisfies the same need without competing with the verdict.
- **No nuance clauses.** No "keep narration brief," no "unless the review is complex."

---

## (2) Verification plan before deploying

This is an edit to an existing prompt template. Iron Law applies to edits too: **no change without a failing test first.** And because the failure is about output *shape*, I verify the wording with micro-tests before any expensive full run.

**RED — establish the baseline (control):**
1. Take 5 real-ish diffs (mix of clean, minor-issue, and blocker cases).
2. Run the reviewer template **without** the new guidance, ≥5 reps. This is the no-guidance control.
3. Confirm the failure actually reproduces: verdicts buried, leading process narration ("First I read..."). **If the control doesn't bury verdicts, stop — there's nothing to fix and no guidance to add.**

**GREEN — micro-test the wording in its real context:**
4. One API call per sample. System prompt = the **full reviewer template with the new format section inserted** (the guidance in the context it'll actually live in, not in isolation). User message = each diff.
5. ≥5 reps per diff.
6. **Read every output manually.** I'm scoring three things:
   - Is line 1 a valid verdict enum?
   - Do verdict + reason precede the first finding?
   - Did narration leak in (especially disguised inside the Reason or Evidence slots)?
   Automated grep for "First I" understates leakage — narration mutates. Manual read required.
7. **Variance is a metric.** If the 5 reps converge on the same shape, the recipe is binding. If I get 5 different interpretations of where the verdict goes, the form is too loose — tighten the slots before adding words.

**Head-to-head check (because this is a shaping failure):**
8. Run a third variant: the same template with a **prohibition** version ("don't narrate your process; lead with the verdict") instead of the recipe. Compare recipe vs prohibition vs control on the same diffs. I expect the recipe to win and the prohibition to score at or below control — confirming I picked the right form, and giving me evidence if someone later asks "why not just tell it not to narrate?"

**REFACTOR:**
9. If narration leaks into a specific slot (likely the Evidence slot becoming a narration dumping ground), tighten that slot's definition — e.g., constrain Evidence to "a quoted snippet or reproduction tied to one finding" — and re-run. Do not add a "don't" clause.

**Deploy** only after recipe reps converge on verdict-first output and beat the control. Commit the template change with the before/after sample outputs attached as evidence.