I need to stop and flag a problem with this request before doing any work.

## The Iron Law applies

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

This applies to **edits** to existing skills, not just new ones. You've asked me to author guidance and *then* give a verification plan. That's backwards — it's writing production code before the test. Per my training, if I write the guidance first, I'd have to delete it and start over.

So I won't hand you finished guidance text as step (1) and a test plan as step (2). Instead, here's how this edit must actually proceed.

## RED first: prove the failure exists

Before writing anything, I need to watch the baseline fail. Right now I'm taking your word that "controllers sometimes ask the next reviewer to re-run the full suite." I need to see it.

**Baseline scenario (run WITHOUT new guidance):**
Give a controller subagent a realistic state:
- A reviewer found 2 issues.
- A fix subagent amended the code and produced a fix report that includes test evidence (e.g., "ran full suite, 412 passed, the 2 failures now green").
- Now the controller must dispatch the next step.

Prompt it to proceed and observe: does it actually instruct the next reviewer to "re-run the full suite to be safe"? Capture the **verbatim rationalization** ("to be safe", "can't trust the fixer's report", "want a clean baseline", etc.).

Run it 3–5 times. If controllers *don't* reliably duplicate the work, **there's no failing test and I should not add guidance** — we'd be adding tokens for a problem that doesn't exist. Possible alternatives if baseline doesn't fail:
- It's a one-off, not a pattern → no skill change.
- The fix report format doesn't actually carry test evidence → fix the *report template*, not add a rule.
- It's mechanically enforceable → automate (have the orchestrator pass the evidence forward) rather than document.

## GREEN: minimal guidance addressing the real rationalizations

Only after I have verbatim baseline rationalizations would I write guidance — and it would target *those exact excuses*, not my guesses. A likely shape (to be written only post-baseline):

- A short rule about trusting fix-report test evidence and not re-running unchanged suites.
- A rationalization table built from the captured excuses ("to be safe" → reality).
- Guidance on *when re-running IS warranted* (fix touched shared/global state, report lacks evidence, fixer's evidence is stale relative to further changes) — so I don't overcorrect into "never re-test."

I can't give you the literal text now without violating the Iron Law and without the baseline data that determines what it should say.

## Description check

I'd also verify the edit doesn't require a description change — per SDO, the description states *when to use*, not workflow. Re-run/skip-rerun is body content, not a trigger.

## Full verification plan before deploying

1. **RED** — run baseline scenario 3–5×, document verbatim rationalizations. If it doesn't fail, stop.
2. **GREEN** — write minimal guidance from those rationalizations; re-run same scenarios; confirm controllers now forward the evidence instead of duplicating.
3. **Overcorrection test** — scenario where re-running *is* justified (no evidence in report / shared-state change); confirm controllers still re-run when appropriate.
4. **REFACTOR** — capture any new loopholes ("but this fix was complex…"), add explicit counters, re-test until bulletproof.
5. **Token cost** — `wc -w` the SDD skill; if it's frequently-loaded, keep the addition tight or push detail to a referenced file.
6. **Deploy** — commit and push only after tests pass.

**Tell me to run the baseline** (or share existing baseline transcripts), and I'll produce the actual guidance text grounded in what the controllers really say.