I'm going to push back before writing anything, because the Iron Law applies to this edit:

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

This applies to edits, not just new skills. But more importantly, your request asks me to "Add guidance" — and before I draft guidance text I need to do something the writing-skills training requires: **classify the baseline failure and match the form to it.** Let me do that work transparently, then give you what you asked for in the correct order (verification *before* deployment, and honestly, the verification should happen before I'm confident in the text at all).

## Step 1: Classify the failure

Your description: the controller knows the fix report carries test evidence, but asks the next reviewer to re-run the suite "to be safe" anyway. That's a **discipline failure under pressure** — specifically redundant-work-from-anxiety, where the rationalization is literally "to be safe." It's not a wrong-shape-output problem and not an omission. So per *Match the Form to the Failure*, the right form is: **a conditional keyed to an observable predicate** (does the fix report contain test evidence?) plus a small rationalization table. Not soft guidance ("prefer trusting the report").

## Step 2: Draft guidance text (PROVISIONAL — not yet earned)

I'll give you a draft so you have something concrete, but I am explicitly NOT calling this deployable. It hasn't been tested.

> ### Don't re-run tests the fixer already ran
>
> When a fix subagent amends code, its fix report carries the test evidence (command, output, pass/fail). The next reviewer reviews the *diff and the report*, not the whole suite.
>
> **If the fix report contains test evidence for the changed code, do NOT ask the next reviewer to re-run the full suite.** Verify the report instead: does the cited command match the change? Does the output show passing? Is the evidence for *this* fix, not a stale run?
>
> **Re-run only when the report's evidence is missing, stale, or doesn't cover the change** — and then re-run the *targeted* tests, not the whole suite, unless the change is suite-wide.
>
> | Rationalization | Reality |
> |---|---|
> | "To be safe" | The fixer already ran them. "Safe" is verifying their evidence, not duplicating it. |
> | "Re-running is cheap" | It isn't — it's serial latency on every fix cycle, and it trains reviewers to ignore reports. |
> | "What if the fixer lied?" | Then the *evidence* is wrong — check the report, don't blindly redo work. |

## Step 3: My verification plan (this must happen BEFORE deployment — and before I trust the text above)

**RED — baseline, no guidance:**
1. Reconstruct the realistic context: SDD skill body as system prompt, a user message presenting a fix report *with* embedded test evidence and asking the controller what to instruct the next reviewer.
2. **Include a no-guidance control.** If the control doesn't actually ask for a redundant full re-run, there's no failure to fix — stop and tell you the premise didn't reproduce.
3. Run 5+ reps. Capture verbatim rationalizations ("to be safe", "just in case", etc.) so the table reflects real excuses, not my guesses.

**GREEN — micro-test the wording (cheap, before full scenarios):**
4. Same context + draft guidance, 5+ reps. Read every flagged match manually — template echoes will masquerade as compliance.
5. Check variance: do reps converge on "verify the report" or scatter? Scatter = wording isn't binding, tighten before adding words.

**REFACTOR:**
6. New rationalizations → add to table → re-test until convergent.
7. Final gate: full pressure scenario (add time pressure + an authority figure who "always re-runs") since this is a discipline skill.

**Then** deploy: confirm I'm editing the actual SDD SKILL.md, commit, push.

I have not run any of this yet. Want me to execute the RED baseline now? If the control doesn't reproduce the redundant re-run, we shouldn't add this guidance at all.