I'll help with this, but I have to follow the Iron Law: **no skill edit without a failing test first.** Let me be explicit about what I'm doing and why.

## Why I won't just hand you final guidance text

The writing-skills discipline treats editing a skill exactly like editing production code. Writing the guidance before watching a controller fail means I'd be guessing at:

- The *exact rationalizations* controllers use when they re-type values ("it's clearer if I inline it," "the subagent might not read the brief," "I'm just being explicit")
- Whether the real failure is a discipline problem (they know better, copy anyway) or a knowledge gap (they don't realize the brief is authoritative)
- What loopholes my guidance needs to close

So below you'll get a *draft* of the guidance and a verification plan — but the draft is provisional. It will almost certainly change after baseline testing, and I'd refuse to deploy it as-is.

## (1) Draft guidance text (PROVISIONAL — pending RED phase)

This is my best guess at GREEN-phase content, to be rewritten based on what baseline testing reveals:

```markdown
## Never Re-Type Exact Values Into Dispatch Prompts

The per-task brief is the single source of truth for exact values:
magic strings, version numbers, function signatures, file paths,
config keys. The implementer subagent reads the brief directly.

**In dispatch prompts, reference — never reproduce — exact values.**

✅ "Implement the retry wrapper per the signature in your brief
    under `## Target Signature`."
❌ "Implement `retryWithBackoff(fn, maxAttempts=5, baseDelayMs=200)`."

**Why:** Every re-typed value is a transcription you can get wrong.
Re-typed values have already shipped bugs. The brief cannot drift
from itself; a copy can.

### Red Flags — STOP

- Typing a literal value that also appears in the brief
- "I'll just inline it so the prompt is self-contained"
- "The subagent might miss it in the brief"
- "It's only one number / one string"
- Copy-pasting a signature, then editing it in the prompt

**All of these mean: delete the literal, point to the brief section.**

| Rationalization | Reality |
|-----------------|---------|
| "Inlining is clearer" | A wrong inline value is worse than clear. |
| "Subagent may not read brief" | Then fix the brief/dispatch, not by copying. |
| "It's just one value" | One value is exactly how transcription bugs ship. |
```

I deliberately kept it minimal. I do NOT want to pre-write counters for rationalizations I haven't yet observed — that's adding content for hypothetical cases.

## (2) Verification plan (the actual work, in order)

### RED — Baseline, BEFORE editing the skill

1. Write 3+ pressure scenarios where a controller fills a dispatch prompt and a brief already contains the exact values. Apply combined pressure:
   - **Time:** "quick task, just dispatch it"
   - **Authority/spec proximity:** spec text with the literal value is right there in context
   - **Self-containment instinct:** "make the prompt standalone"
2. Run each scenario with a subagent that has the **current** SDD skill (no new guidance).
3. Record verbatim:
   - Do they re-type values? Which kinds (strings, signatures, versions)?
   - Exact rationalizations they give.
   - Whether failures are discipline (knew, copied anyway) vs. knowledge (didn't know brief was authoritative).

If baseline controllers *don't* re-type values, the skill doesn't need this edit and I stop.

### GREEN — Write minimal guidance addressing observed failures

4. Rewrite the draft above to target the *actual* baseline rationalizations and failure mode (discipline vs. knowledge). Drop counters nobody actually used; add ones they did.
5. Re-run the same scenarios WITH the new guidance. Confirm controllers now reference instead of reproduce.

### REFACTOR — Close new loopholes

6. Capture any NEW rationalizations agents invent ("I referenced it but also pasted it as a comment"). Add explicit counters. Re-test until clean.
7. Check the SDD `description` field: it must NOT summarize this workflow (agents would follow the summary and skip the body). Only add a triggering symptom if needed.

### Deploy

8. Verify token cost is justified (SDD likely loads often — keep it tight). Commit and push.

Want me to start the RED phase by drafting the three baseline scenarios?