I'll help with this, but first I need to flag the Iron Law: **no skill edit without a failing test first.** Let me apply the writing-skills process properly rather than just drafting text.

Let me also classify this failure before drafting anything, because the form matters.

## Classifying the failure

The controller "asks the next reviewer to re-run the full test suite 'to be safe.'" This is a **discipline failure under pressure** — the safety-seeking impulse ("to be safe") overrides available evidence (the fix report's test results). The controller likely *could* check the fix report but skips that reasoning under the pull of caution.

But there's a conditional element too: re-running is sometimes legitimate (e.g., the fixer's evidence is stale or doesn't cover the changed surface). So pure prohibition ("never re-run tests") would backfire — it would suppress legitimate re-runs and invite "this case is different" rationalizations.

**Right form:** a conditional keyed to an observable predicate (does the fix report carry passing test evidence covering the change?), plus a small rationalization counter for the "to be safe" impulse.

## (1) Proposed guidance text

> ### Don't re-verify what the fix report already proves
>
> When a fix subagent amends code, its report carries the test evidence (command run, result, scope). The next reviewer reviews the *diff and the report* — it does not re-run the suite by default.
>
> **Before asking a reviewer to re-run tests, check the fix report:**
> - Does it show the test command that was run, and that it passed?
> - Does that run cover the changed code?
>
> If both are true, **do not re-run.** Review the evidence instead.
>
> **Re-run only when the report fails an observable check:** no test command shown, tests not passing, or the changed surface is outside what the reported run covered. Name which check failed when you request the re-run.
>
> | Rationalization | Reality |
> |---|---|
> | "Re-run to be safe" | "Safe" against what? If the report shows a passing run covering the change, re-running tests the same thing twice. Name the gap or skip it. |
> | "The fixer might have missed something" | Then point at *what* the report fails to cover. A specific gap justifies a re-run; a vague feeling doesn't. |
> | "It's cheap to just run it again" | It duplicates the fixer's work and trains reviewers to ignore fix evidence. The cost is the habit. |

(Final wording is provisional — testing may change it.)

## (2) Verification plan before deploying

I will **not** ship this until it has passed the RED→GREEN cycle. Plan:

**RED — baseline (write the failing test first):**
1. Construct a pressure scenario: controller has a reviewer-issues-found → fixer-amended state, where the fix report clearly shows a passing test run covering the change. Add the "to be safe" pressure ("the controller is cautious; production incident last week").
2. Run this scenario with a subagent **without** the new guidance, 5+ reps.
3. Document verbatim: do they request a redundant re-run? What words do they use ("to be safe", "just in case")? Capture every rationalization for the table.
4. **If the baseline doesn't reproduce the redundant re-run, stop** — there's nothing to fix and I won't author guidance for a non-problem.

**Micro-test the wording (cheap iteration before full scenarios):**
5. One API call per sample, system prompt = the full SDD skill with the candidate guidance embedded, user message = the tempting task. Always include a no-guidance control.
6. 5+ reps per variant. Read every flagged match manually — watch for the conditional being misread as "never re-run" (over-suppression) or the predicate being ignored.
7. **Variance check:** confirm reps converge on the same behavior (check report → skip if covered). Five different interpretations = wording not binding; tighten before adding words.

**GREEN — verify compliance:**
8. Re-run the original pressure scenario **with** the guidance. Confirm reviewers now read the fix report and skip the redundant re-run.

**Counter-test (guard against over-correction):**
9. Run a scenario where the fix report's run does **not** cover the changed surface (genuine gap). Confirm reviewers *do* re-run and *name the gap*. If they now blanket-skip even legitimate re-runs, the conditional failed and I tighten the predicate.

**Only after both GREEN and the counter-test pass** do I finalize the table from observed rationalizations, then commit.

Want me to start with the RED baseline scenario, or refine the predicate wording first?