I'll start by classifying the failure type, because that determines the form of the guidance — and the writing-skills training is explicit that getting this wrong measurably backfires.

## Classifying the failure

Let me look at what's actually happening:

- The controller **adds** a redundant instruction ("re-run the full suite to be safe") to a re-review they already dispatch.
- They do this even though the fix report **already carries** the test evidence.
- This is conditional behavior gone wrong: the right action depends on an observable predicate (does the fix report contain passing test evidence?).

This is **not** a discipline failure (knowing a rule and skipping it under pressure). And it's not a wrong-shaped-output problem either. It's the **conditional** row in *Match the Form to the Failure*:

> Behavior should depend on a condition → **Conditional keyed to an observable predicate.** Wrong form: unconditional rule + exemption clauses.

So I should NOT write a prohibition ("Never ask reviewers to re-run tests"). A flat prohibition backfires — there are legitimate cases (the fix touched code the reported tests don't cover, the report shows no test evidence). A prohibition forces exemption clauses, and exemption clauses don't scope cleanly. The right form is a conditional keyed to "does the fix report contain passing test evidence for the relevant changes?"

But per the Iron Law, **I cannot write this guidance yet.** No skill (or edit) without a failing test first. Below is the guidance I *propose* — but it's contingent on the baseline test confirming the failure exists and the wording micro-test confirming the wording binds.

---

## (1) Proposed guidance text

To be added to the SDD skill in the re-review dispatch section:

```markdown
### Trust the fix report's test evidence

When a fix subagent amends code in response to review findings, its fix
report carries the test evidence (which tests ran, their results). The
re-review's job is to verify the findings were addressed — not to
re-establish ground already covered by the fixer.

**Before adding a re-run instruction, check the fix report:**

- **Fix report shows passing tests covering the changed code** →
  reference that evidence in the re-review dispatch. Do NOT instruct
  the reviewer to re-run the suite. The tests already ran; re-running
  is duplicated work, not added safety.

- **Fix report shows no test evidence, OR the fix touched code the
  reported tests don't exercise** → instruct the reviewer to run the
  specific tests covering the gap, and say which gap.

"To be safe" is not a reason to re-run tests that already passed. Safety
comes from reading the evidence, not from repeating the work that
produced it.
```

Design notes (why this form):
- **Conditional keyed to an observable predicate** — "does the fix report contain passing test evidence covering the changed code?" — not an unconditional rule.
- The legitimate re-run case (gap/no-evidence) is its **own conditional**, not an exemption clause bolted onto a prohibition. This matters: exemption clauses don't scope.
- "To be safe" is named explicitly because it's the verbatim rationalization in the report — but the counter is a *redirect to the predicate*, not a "don't."

---

## (2) Verification plan before deploying

I will not deploy on confidence. The plan follows RED → micro-test → GREEN/REFACTOR.

**Step 0 — Confirm the skill exists and locate the insertion point.** This is an edit to an existing skill; the Iron Law applies to edits too.

**Step 1 — RED: baseline, no guidance (5+ reps).**
- Context (system prompt): the realistic controller context — the existing SDD skill *without* the new section, plus a re-review dispatch task.
- User message: a fixer's fix report that **clearly contains passing test evidence covering the changed code**, then "dispatch the re-reviewer."
- Run 5+ reps. **Score by reading each output manually:** does the controller inject "re-run the suite / to be safe" despite the evidence?
- **If the control does NOT exhibit the failure → stop. There's nothing to fix; don't author the guidance.** (The report says "sometimes" — I need to confirm it reproduces.)

**Step 2 — Micro-test the wording against the control (5+ reps each).**
- Variant A: no guidance (control, from Step 1).
- Variant B: proposed conditional guidance above.
- (Optional Variant C: a prohibition phrasing — "Never ask reviewers to re-run passing tests" — to confirm the conditional form scores *better*, since the training warns prohibitions backfire on non-discipline failures. This guards against me picking the wrong form.)
- Read every flagged match manually — template echoes and quoted "to be safe" counter-examples will masquerade as hits.

**Step 3 — Test BOTH predicate branches (this is the critical check).**
- **Branch 1 — evidence present:** as Step 1. Pass = no re-run instruction, evidence referenced.
- **Branch 2 — evidence absent / gap:** fix report shows the fix touched code the reported tests don't cover. Pass = controller instructs running the *specific* gap tests and names the gap.
- A conditional that suppresses re-runs in *both* branches is over-broad and unsafe — it would teach controllers to trust missing evidence. This branch test is what a prohibition would fail.

**Step 4 — Variance check.** If 5 reps converge on the same shape (reference evidence, no re-run) in Branch 1, the wording binds. Five different interpretations = tighten the form before adding words.

**Step 5 — REFACTOR.** Capture any new rationalization ("the fixer might have a stale report," "different machine") and decide: is it a real predicate (→ add as its own conditional) or a rationalization (→ counter it)? Re-test.

**Step 6 — Deploy** only after both branches pass and variance is low: commit, push.

**Deferred until tests pass:** I'm treating the guidance text above as a *proposal contingent on Step 1*. If the baseline doesn't reproduce the failure, I discard it rather than keep it as "reference."