I'll apply the Iron Law here: **no skill edit without a failing test first.** Let me be explicit about what I can and can't responsibly hand you.

## The Honest Constraint

You asked for (1) the exact text and (2) my verification plan. But writing-skills forbids producing the edit *before* watching the current template fail under controlled conditions. So I'm going to give you the text as a **candidate**, clearly marked as untested, and front-load the verification that gates its deployment.

If I handed you polished text and called it done, I'd be deploying untested process documentation — exactly the violation this skill exists to prevent.

---

## (1) Candidate text to add to the reviewer prompt template

> ```
> ## Report Format (REQUIRED)
>
> Lead with the verdict. The first line of your report MUST be one of:
>
>   VERDICT: PASS
>   VERDICT: FAIL — <one-line reason>
>   VERDICT: BLOCKED — <what you could not assess and why>
>
> Immediately after the verdict line, list findings as bullets, most
> severe first. Each finding: what is wrong, where, and the fix.
>
> Do NOT narrate your process. The controller does not need to know the
> order you read files, what you checked first, or how you reasoned to
> get here. Report conclusions, not the journey.
>
> Process notes, if genuinely useful (e.g. "did not review generated
> files"), go in a final "Scope & caveats" section AT THE END — never
> before the verdict.
> ```

This is **not deployable yet.** It's the artifact under test.

## (2) Verification plan (this gates deployment)

**RED — establish baseline (must run BEFORE trusting the text above):**
1. Collect 3–4 real diffs of varying outcomes (a clean one, one with a bug, one with something ambiguous/un-reviewable).
2. Run the reviewer with the *current, unedited* template on each.
3. Record verbatim: Where does the verdict appear? How many lines of process narration precede it? Capture the exact narration phrasings ("First I read…") so I know what I'm actually fighting.

This step is the point. If I never watch the current template bury verdicts under specific phrasings, I'm guessing at what the edit needs to counter.

**GREEN — test the edit:**
4. Run the *edited* template on the same diffs.
5. Pass criteria: verdict on line 1 in every report; zero process narration before findings; findings ordered by severity.

**REFACTOR — close loopholes:**
6. Look for evasions the baseline or new runs reveal — e.g., reviewer writes `VERDICT: PASS` then *still* narrates process in findings, or smuggles narration into the caveats section, or hedges the verdict ("VERDICT: PASS, though I should mention I first…"). Add explicit counters for whatever actually shows up. Re-run until clean across all diffs.

**Specific risk to watch:** the BLOCKED verdict. Reviewers under uncertainty love to narrate *instead* of committing to a verdict. The baseline run will tell me whether "BLOCKED" gets used cleanly or becomes a new narration vector — and that may change the text.

---

**Bottom line:** the text in (1) is a hypothesis. (2) is what turns it into a skill edit I'd actually deploy. Want me to start with the RED baseline runs, or do you have existing reviewer reports I can use as the failing-test corpus instead of generating fresh ones?