I'm going to stop you on the sequencing here, because the request as framed would have me write the guidance text first and then plan verification. That's backwards from how this skill library is maintained.

## The Iron Law applies to this edit

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

This applies to **edits to existing skills**, not just new ones. The writing-skills training is explicit:

> Edit skill without testing? Same violation.
> Not for "just adding a section"

So I can't responsibly hand you "(1) the exact guidance text" as a finished artifact before running a baseline. If I write it now, I'd be producing untested documentation — and I'd then be tempted to keep it as "reference" and adapt it during testing, which the skill specifically forbids.

Here's what I'll do instead.

## Why baseline first matters *specifically here*

I have a hypothesis about the behavior ("controllers redundantly request full re-runs"), but I don't actually know:

- **What rationalizations controllers use** ("to be safe", "the fixer might have missed something", "fresh eyes need fresh data"). I need these *verbatim* to write counters.
- **Whether the real failure is redundancy or insufficient trust in the fix report.** If the fix report's test evidence is weak/unstructured, the right fix might be to strengthen the report format, not to forbid re-runs. Writing "don't re-run" guidance would then paper over a real gap and could let regressions through.
- **When re-running IS correct** (e.g., fix touched shared code outside the reported scope). A skill that says "never re-run" would be wrong; I need the boundary, and baseline reveals it.

Writing the text first risks solving the wrong problem confidently.

## My verification plan (this comes first, not second)

**RED — establish baseline (no edit yet):**
1. Read the current SDD skill to find where review/fix handoff is described and what the fix report format actually contains.
2. Run 3+ pressure scenarios with subagents acting as the controller after a fix, *without* any new guidance:
   - Plain case (fix report has clean test evidence, fix scoped to reported lines).
   - Pressure case: a senior voice in the scenario says "always re-run to be safe."
   - Edge case: fix touched a shared module beyond the reported scope.
3. Record exact choices and rationalizations verbatim. Confirm the redundant-rerun behavior actually reproduces, and capture whether subagents distinguish the edge case.

**GREEN — minimal edit:**
4. Write guidance addressing *only* the rationalizations observed, including the legitimate exception(s) baseline reveals (likely: re-run only when the fix touched code outside the report's tested scope).
5. Re-run the same scenarios. Verify controllers now trust the fix evidence in the plain/pressure cases and still re-run in the genuine edge case.

**REFACTOR:**
6. Capture any new rationalizations, add explicit counters, build a rationalization table, re-test until stable.

**Deploy:** commit only after scenarios pass.

## What I need from you to start

1. Point me at the SDD skill path (and confirm the fix report format — does it already carry structured test evidence, or is that aspirational?).
2. Confirm I should run the baseline subagent scenarios now.

Once baseline is done I'll bring back the *tested* guidance text — which is the artifact actually worth having.