I'm going to push back before writing anything, because the Iron Law applies here: **no skill edit without a failing test first.** Let me also classify the failure before drafting, because that determines the form of the guidance.

## Classifying the failure

The controller "asks the next reviewer to re-run the full test suite to be safe" even though the fix report carries test evidence. That's a **behavior that should depend on a condition** — re-run iff there's a reason to doubt the fix report's evidence — not a flat rule, and not a discipline failure where the agent knows better and skips anyway.

Per *Match the Form to the Failure*, the right form is a **conditional keyed to an observable predicate**, not a prohibition ("never re-run the suite"). A prohibition would backfire: it would suppress legitimate re-runs (e.g., when the fix touched code the report didn't cover) and invite negotiation under the "to be safe" incentive.

## (1) Exact guidance text

```markdown
## Re-running tests after a fix

When a fix subagent amends code, its fix report carries the test evidence
(command run, pass/fail counts, relevant output). Treat that evidence as the
default basis for the next review.

Trust the fix report's test evidence when ALL of these hold:
- The report names the exact command(s) run.
- The reported scope covers the code the fix changed.
- The reported result is a pass (or an explained, expected failure).

Re-run tests yourself ONLY when one of these observable conditions holds:
- The fix report is missing test evidence, or doesn't name the command run.
- The fix changed code outside the scope the report's tests covered.
- The report shows a failure that isn't explained.
- You changed code yourself during this review.

"To be safe" is not one of these conditions. If the three trust conditions
hold and none of the re-run conditions do, do not re-run — cite the fix
report's evidence in your review instead.
```

Note: the closing line names the exact rationalization ("to be safe") and ties the decision to observable predicates, not vibes. There is no nuance clause — each re-run trigger is its own checkable condition.

## (2) Verification plan before deploying

I will NOT deploy this until it passes RED → GREEN, and I'll micro-test the wording before burning full scenarios.

**RED — baseline (must see the failure first):**
1. Build a realistic system prompt: the SDD review-controller context *without* this new guidance.
2. User message: a review handoff where the fix report contains complete, in-scope, passing test evidence, plus a controller note nudging "to be safe."
3. Run 5+ reps. **Record verbatim** how often the controller orders a redundant re-run and the exact rationalizations used.
4. If the no-guidance control does NOT produce redundant re-runs, **stop** — there's nothing to fix and I shouldn't author guidance.

**Micro-test the wording (wording gate, cheap iteration):**
5. Same setup, system prompt now includes the draft guidance. 5+ reps.
6. **Manually read every result** — don't trust a keyword count; a reviewer quoting "to be safe" while correctly declining is a pass, not a hit.
7. Check variance: if the 5 reps diverge (some re-run, some don't, on the same inputs), the conditional isn't binding — tighten predicates before adding words.

**GREEN + boundary tests (confirm it doesn't over-correct):**
8. **Positive case:** evidence complete and in-scope → reviewer cites the report, does not re-run. Expect compliance.
9. **Legitimate re-run, must still fire:** fix changed code outside the report's tested scope → reviewer SHOULD re-run. This guards against the prohibition-style backfire where the agent stops re-running when it should.
10. **Missing-evidence case:** report omits the command → reviewer re-runs.
11. **Self-edit case:** reviewer modified code during review → reviewer re-runs.

**REFACTOR:**
12. Capture any new rationalization ("the controller explicitly asked," "more coverage never hurts") and add it as an observable counter only if a real run produces it — not preemptively.
13. Re-test until both the redundant-re-run case and all three legitimate-re-run cases behave correctly across 5+ reps.

I'll only commit after step 13 passes. If you can confirm the baseline failure is real (or share logs of it), that satisfies RED and I'll proceed to the micro-tests.