I'll apply the Iron Law here. Before I write any guidance text, I need to follow RED-GREEN-REFACTOR — and that means I cannot hand you finished template text as if it's deployable. Let me be honest about what's actually deliverable versus what requires testing first.

## The Iron Law applies to this edit

```
NO SKILL WITHOUT A FAILING TEST FIRST
```

This is an edit to guidance (the reviewer prompt template is process documentation). I haven't watched a reviewer agent fail yet in a controlled way, and I haven't watched candidate guidance fix it. So anything I write below is a **GREEN-phase candidate**, not approved text. I'm labeling it that way deliberately — don't deploy it before the verification plan runs.

I also need to flag a likely trap: my first instinct is to write guidance that *describes the desired output format in prose*. But the writing-skills training warns that descriptions/summaries become shortcuts agents take instead of doing the real work. The fix here is probably **structural** (a required output template the reviewer fills in) rather than **exhortative** ("please lead with the verdict"). I won't know which works until I test both.

---

## (1) Candidate text to add — UNTESTED, GREEN-phase only

I'd test this against alternatives before committing. Candidate:

```markdown
## Output format (required)

Produce your report in exactly this order. Do not add a preamble.

### Verdict
PASS / FAIL / NEEDS-CHANGES — one line, first thing in the report.

### Blocking issues
- Numbered list. Empty list = write "None".

### Required changes
- Numbered list. Empty list = write "None".

### Evidence
For each verdict above, cite the specific file/line/diff hunk that justifies it.

---

Do NOT narrate your process ("first I read...", "then I checked..."). The
controller needs conclusions and evidence, not the order you discovered them.
If you find yourself writing "first/then/next/after that", delete that
sentence — it belongs in your scratch work, not the report.
```

Why this shape (hypotheses to be tested, not facts yet):
- **Verdict first, as a fixed slot** — structure forces it to the top rather than asking the agent to remember to.
- **"Empty list = None"** — closes the loophole where agents skip a section and the controller can't tell "no issues" from "forgot to check".
- **Explicit ban on process words with a self-check** — process narration was the observed symptom, so I name the exact trigger words.

---

## (2) Verification plan (must run BEFORE deploying)

**RED — establish baseline (the part I haven't done):**
1. Collect 3–5 real diffs of varying outcomes (a clean PASS, a clear FAIL, a borderline NEEDS-CHANGES, one with multiple issues).
2. Run the **current** template (no edit) on each via subagents.
3. Record verbatim where verdicts land and how much process narration appears. Confirm the failure is real and characterize it: Is it always buried? Buried only on complex diffs? This tells me what the edit must actually fix.

**GREEN — test the candidate:**
4. Run the **edited** template on the same diffs.
5. Pass criteria: verdict is the first line on 100% of runs; no "first/then/next" narration in the report body; every verdict has cited evidence; empty sections say "None" not omitted.

**REFACTOR — close loopholes under pressure:**
6. Stress scenarios: a huge diff (does the agent revert to narration to "organize its thinking"?), an ambiguous case (does it hedge instead of giving a clean verdict?), and a diff where it's genuinely uncertain (does it still lead with a verdict, or bury it under caveats?).
7. Capture any new rationalizations verbatim ("I added context so the controller understands...") and add explicit counters, then re-run.

**Comparison test (important):**
8. Also run a *prose-only* variant ("Lead with your verdict; avoid narration") with no structural template, on the same diffs. The writing-skills training predicts the prose-only version will underperform because agents follow the description-summary shortcut rather than restructuring. If that prediction holds, it justifies the rigid template. If prose-only works just as well, the lighter touch is better. Let the test decide.

**Deploy gate:** only commit the edit after the candidate passes RED→GREEN→REFACTOR and beats the prose-only variant.

---

If you want, I can run the RED baseline now — but I need either the actual current reviewer template text or sample diffs to run scenarios against. Without watching it fail first, I'd just be shipping untested documentation, which is the one thing this process forbids.