I'll help with this, but I have to push back on doing it in the order requested. The Iron Law applies here:

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

This applies to **edits** to existing skills, not just new ones. You've asked for (1) the guidance text and (2) the verification plan — in that order. But writing the guidance before running the baseline is exactly the violation the skill warns against. So let me flip it: verification plan first, and the guidance text only as a *candidate* to be tested, not as deployable output.

## First: classify the failure

This is the critical step that determines what form the guidance takes. Let me read your description carefully:

> controllers sometimes ask the next reviewer to re-run the full test suite "to be safe", duplicating work the fixer already did (the fix report carries the test evidence)

This is **not** a discipline failure (someone knowing a rule and skipping it under pressure). It's closer to a **conditional-behavior** problem: the controller should rely on existing test evidence *when the fix report carries it*, and only re-run when it doesn't (or when the change invalidates it).

Per "Match the Form to the Failure," the right form is a **conditional keyed to an observable predicate** — not a prohibition like "never re-run tests." A flat prohibition would backfire: re-running tests is sometimes correct (e.g., the fix touched files outside the reported scope, or the report's evidence is stale). An unconditional "don't re-run" with exemption clauses doesn't scope cleanly.

So I can already tell you the *shape* of the candidate, but I cannot tell you it works until baseline + micro-tests run.

## Verification plan (this comes first)

**RED — baseline, before writing anything:**

1. **Establish the control exhibits the failure.** Construct 5+ scenarios: a reviewer was dispatched, a fix subagent amended code and produced a fix report containing test evidence (passing suite). System prompt = the current SDD skill *as-is*. User message = the controller's task ("dispatch the next reviewer"). Measure: does the controller instruct a full suite re-run "to be safe"?
   - If the control does NOT exhibit this, **stop** — there's nothing to fix, and I'm not adding guidance for a phantom problem.
2. **Capture verbatim rationalizations** ("to be safe", "can't trust the fixer's tests", etc.) and note the conditions — does it re-run even when the fix is scoped and evidence is fresh? Does it ever correctly skip?

**GREEN — micro-test the wording:**

3. One API call per sample, system prompt = full skill *with candidate guidance inserted*, 5+ reps per variant.
4. **Variants to compare head-to-head:**
   - no-guidance control
   - prohibition wording ("don't re-run tests if the fix report has evidence")
   - conditional/recipe wording (keyed to the predicate)
5. **Read every flagged match manually** — a controller quoting "the report carries evidence" back at me isn't compliance; check it actually skips the redundant run AND still re-runs in the legitimately-stale case.
6. **Test the negative cases too:** fix touched files outside reported scope, or report lacks evidence. Correct behavior there is to re-run. If the guidance suppresses the *legitimate* re-run, it's too strong.
7. **Variance is a metric** — if 5 reps interpret the predicate 5 different ways, tighten the predicate before adding words.

**REFACTOR:**

8. Build rationalization table from observed excuses, re-test until convergent.

**Pressure scenarios** (final gate, only if this turns out to have a discipline component): combine time pressure + authority ("the lead always re-runs").

## Candidate guidance (to be tested, NOT deployed)

Conditional form, keyed to observable predicates:

> **Before asking a reviewer to re-run the test suite, check the fix report.** If the fix report carries test evidence (suite run, results) AND the amendment is confined to the files the report covers, pass that evidence to the next reviewer instead of requesting a re-run. Re-run only when: the report lacks test evidence, the amendment changed files outside the report's stated scope, or the evidence predates the latest change.

## What I need from you

I can run the verification myself if you grant me a subagent/API harness, or you run it. Either way I won't hand you the guidance as finished output until baseline confirms the failure is real and micro-tests confirm the conditional wording beats the control without suppressing legitimate re-runs. If baseline shows controllers already behave correctly, we ship nothing.