I'm going to push back before writing anything, because the request asks me to skip the most important step.

## The Iron Law applies here

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

This applies to **edits** to existing skills, not just new ones. You're asking me to:
1. Write guidance text
2. Then verify it

That's backwards. That's writing production code before the test. The writing-skills discipline is explicit:

> Write skill before testing? Delete it. Start over.
> Edit skill without testing? Same violation.

If I hand you polished guidance text now, I've already violated the discipline — and worse, you might deploy it. So I won't produce "the exact guidance text" as a finished artifact yet. Here's what I'll do instead.

## Why this matters for THIS specific change

I don't actually know what controllers naturally do here. The request describes a behavior ("re-run the full suite to be safe"), but I haven't watched it happen. Without a baseline I'd be guessing at:

- **What rationalization drives it.** Is it "to be safe"? Is it distrust of the fix report? Is it not knowing the report carries test evidence? Each implies different guidance.
- **Whether guidance even fixes it.** Maybe the controller can't *find* the test evidence in the fix report — that's a report-format problem, not a guidance problem. Telling controllers "don't re-run" wouldn't help if they literally can't locate the evidence.
- **What new loophole replaces it.** "Re-run to be safe" might become "well, I'll just re-run the *touched* tests to be safe" — same waste, new excuse.

Guessing produces guidance that reads well and changes nothing. I've seen descriptions that "obviously" worked fail under test.

## My plan (RED → GREEN → REFACTOR)

**RED — establish baseline (do this first, before writing guidance):**

1. Write 3+ pressure scenarios where a subagent plays the controller after a fix-report comes back. Combine pressures: time ("review is the last gate before merge"), authority ("the fixer is junior"), and safety-culture ("better safe than sorry"). Include the actual fix report *with* embedded test evidence so I can see whether they read it.
2. Run scenarios WITHOUT new guidance. Capture verbatim:
   - Do they re-run the full suite? Partial? Not at all?
   - Exact rationalizations they use.
   - Do they even notice the test evidence in the report?
3. Look for the pattern. The verbatim excuses become the rationalization table.

**GREEN — write minimal guidance addressing what I actually observed:**

4. Add guidance to the SDD skill that targets the *specific* baseline failures — not hypothetical ones. Likely a "don't duplicate verified work" rule plus a pointer to where the fix report's evidence lives. If baseline shows they couldn't find the evidence, the fix is partly about report format, not just a "don't re-run" rule.
5. Re-run the same scenarios WITH the guidance. Confirm compliance.

**REFACTOR — close loopholes:**

6. Note new rationalizations ("partial re-run to be safe", "the report could be stale"). Add explicit counters and a red-flags list.
7. Re-test until it holds under combined pressure.

**Deploy only after GREEN holds.**

## What I need from you

- Access to a representative **fix report** (so scenarios use the real format and I can test whether evidence is findable).
- Confirmation of the trigger I should put in the description: this is "Use when reviewing code after a fixer has amended it in response to a prior review" — *triggering condition only*, no workflow summary (a description that summarizes "don't re-run" would let agents act on the description and skip the skill body).

Want me to start by drafting the RED-phase pressure scenarios so you can sanity-check them before I run the baseline?