I need to flag something before doing this work: the request asks me to write the guidance text first, then verify it. That's backwards from the Iron Law that governs this skill library.

## The Iron Law applies here

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

This explicitly applies to **edits**, not just new skills:

> This applies to NEW skills AND EDITS to existing skills.
> Edit skill without testing? Same violation.

So I won't hand you finished guidance text as item (1) and a verification plan as item (2). Writing the text before establishing the baseline is the violation. The verification (specifically the RED baseline) has to come *first* and *shape* the text. Let me do it in the correct order and show my work.

## RED Phase — establish the baseline (must happen before writing)

I cannot write guidance for a failure I haven't actually observed. The premise describes a behavior ("controllers ask the next reviewer to re-run the full suite to be safe"), but I need to confirm:

1. **Does it actually happen?** Run 3+ pressure scenarios with a controller subagent: a fix report arrives carrying test evidence, and the controller decides what to tell the next reviewer. Pressures to combine: "to be safe," a flaky-test history, an authority nudge ("the lead always re-runs everything"), and sunk-cost ("we already paid for the fixer's run, one more won't hurt").
2. **Capture verbatim rationalizations.** I need the exact phrasings controllers use ("just to be safe," "tests are cheap," "the fixer might have only run affected tests"). Those phrasings become the rationalization table — I can't invent them.
3. **Identify the legitimate exception.** Re-running is *correct* when the fix touched something the original evidence doesn't cover. The guidance must not forbid justified re-runs, or I'll create a worse failure mode (trusting stale evidence). The baseline will tell me where that line actually is.

## GREEN Phase — write minimal guidance addressing observed failures

Only after seeing the baseline do I write text targeting *those specific* rationalizations. Likely shape (will be adjusted to fit real data):

- A rule: trust the fix report's test evidence; don't order a blanket re-run by default.
- An explicit exception: re-run only the tests covering surfaces the fix changed but the evidence doesn't cover.
- A rationalization table built from verbatim baseline excuses.
- A red-flags list ("to be safe," "tests are cheap," "might as well").

## REFACTOR Phase — close loopholes

Re-run scenarios *with* the new guidance. When the controller finds a new dodge ("technically the report's evidence is from before the amend"), add a counter. Repeat until controllers comply under combined pressure without suppressing legitimate re-runs.

## Verification plan (the actual answer to your item 2, expanded)

1. Locate the real SDD skill file and read the surrounding sections so guidance fits the existing structure and cross-references.
2. RED: 3+ combined-pressure controller scenarios, no guidance present. Log behavior + verbatim rationalizations.
3. GREEN: write minimal guidance; re-run identical scenarios; confirm controllers now skip redundant re-runs while still ordering justified ones.
4. REFACTOR: capture new rationalizations, plug, re-test to bulletproof.
5. Token check (`wc -w`), keyword coverage, common-mistakes/red-flags sections.
6. Commit only after GREEN holds.

## What I need from you to proceed

Where is the SDD skill in the library (exact path)? I'll read it, then run the RED baseline. I'll bring you the guidance text once it's been shaped by real baseline data and survived the refactor pass — not before.

If you specifically want a *draft to react to* rather than a deployable edit, tell me that explicitly and I'll mark it clearly as an untested sketch, not skill content — but I won't deploy it without running the cycle.