I'm going to push back before writing anything, because the Iron Law applies here.

## The problem: you're asking me to skip RED

The request is "add guidance to the SDD skill." That's an edit to an existing skill. Per writing-skills:

> **The Iron Law (Same as TDD):** NO SKILL WITHOUT A FAILING TEST FIRST. This applies to NEW skills AND EDITS to existing skills.

I haven't watched any agent fail yet. I don't have the baseline. Writing the guidance text now and "verifying after" is exactly the tests-after anti-pattern. So I can't hand you finished guidance text as item (1) in good conscience — that would be production code written before the failing test.

What I *can* do is design the test first, predict what I'll write, and commit to drafting the actual text only after observing the baseline.

## What I'd actually do

**RED — establish the baseline (this comes first, before any guidance text)**

Run pressure scenarios with subagents acting as the controller, given the SDD skill *as it exists today* (no new guidance). The scenario:

- A reviewer found issues; a fix subagent amended the code and produced a fix report containing test evidence (the suite passed post-fix).
- The controller must decide what to instruct the next reviewer to do.
- Apply pressure: "to be safe," "it's cheap," "what if the fixer's run was stale," reviewer-thoroughness norms, "better redundant than sorry."

I need to observe:
- Do controllers actually re-run the full suite redundantly? (Confirm the problem is real and reproducible — you've reported it anecdotally; I need to see it.)
- What *exact rationalizations* do they use? ("to be safe," "I didn't see the run myself," "evidence could be stale.")
- Under what conditions is re-running actually *correct*? (e.g., fixer touched test infra, evidence is missing/partial, fix landed on a different base.) This matters — the guidance must not forbid legitimate re-runs.

If controllers *don't* exhibit the behavior under pressure, there's no failing test, and possibly no skill change needed. I'd report that back to you rather than invent a fix.

**GREEN — write minimal guidance addressing the observed rationalizations**

Only after baseline do I draft text. Its shape (predicted, not final — the verbatim rationalizations from RED determine the real wording):

- A rule: trust the fix report's test evidence as the default; do not instruct redundant full-suite re-runs.
- An explicit list of the *only* conditions that justify re-running (drawn from what RED reveals is legitimate), so "to be safe" isn't one of them.
- A rationalization table built from verbatim baseline excuses.

**REFACTOR — re-test and close loopholes**

Re-run the same scenarios with the new guidance. If controllers find a new loophole ("the report didn't show *which* tests"), add a counter and re-test until it holds — while confirming they *still* re-run in the genuinely-required cases (no overcorrection into skipping necessary verification).

## My answer to your two outputs

**(1) The exact guidance text:** I won't produce it yet — doing so before RED violates the Iron Law and risks writing guidance against an imagined problem instead of the real rationalizations. I'll produce it after the baseline run.

**(2) Verification plan:** That's the RED → GREEN → REFACTOR plan above, and it must run *before* deployment, not after the text is written.

If you want to proceed, I'll run the baseline scenarios now and bring back the verbatim rationalizations plus the legitimate-re-run conditions — then we'll have a real failing test to write the guidance against. Want me to start the RED phase?