Before I write the guidance, let me classify the failure against the Iron Law and "Match the Form to the Failure," because that determines what form the guidance should take.

## Failure classification

The controller already produces a dispatch prompt. The problem isn't that they skip a rule under pressure (discipline failure) — it's that something they reliably produce has the **wrong content shape**: it restates exact values that already live in the brief file the subagent reads.

That puts this in the **"output has the wrong shape" / "omits a required element"** rows of the table, NOT the discipline row. Per the skill, prohibitions ("never re-type exact values", "don't copy version numbers") measurably backfire on shaping problems — under the competing incentive of "make the dispatch prompt self-contained," the controller will negotiate with the prohibition and may re-type *more*. So I should NOT lead with a "don't" list. I should give a **positive recipe / contract** for what the dispatch prompt IS, plus a **conditional keyed to an observable predicate** (the brief file exists).

Also note: there's a real exception (a value that does NOT exist in the brief). I express that as its own conditional, not as a nuance clause on a prohibition.

---

## (1) Exact guidance text to add

```markdown
## Dispatch prompts reference the brief; they don't restate it

Every implementer task has a brief file. The brief is the single source of
truth for exact values: magic strings, version numbers, function signatures,
file paths, config keys, error messages. The subagent reads the brief.

A dispatch prompt is a **pointer plus intent**, built from these parts in order:

1. **Brief reference** — the path to the brief file for this task.
2. **Goal** — what done looks like, in your own words.
3. **Pointers, not values** — when you must direct the subagent to a specific
   value, name *where it lives* in the brief ("use the version pinned under
   `dependencies` in the brief", "match the signature in the brief's API
   section"). The subagent reads the literal value from the brief.

If a value the subagent needs is NOT in the brief, stop: add it to the brief
first, then point at it. The dispatch prompt is never the place a value first
appears.

**Self-check before dispatching:** Could you delete every exact value from
this prompt and replace it with "see the brief", and would the subagent still
have everything? If yes, do that. If no, the missing value belongs in the
brief, not the prompt.
```

Notes on form choices:
- **Recipe/contract** (numbered parts in order) is the right form for a wrong-shape failure — it states what the output IS, leaving nothing to negotiate.
- The exception (value not in brief) is its own **conditional on an observable predicate** ("NOT in the brief"), with a concrete action, not a nuance clause hanging off a prohibition.
- The self-check is a **deletability test** — an observable predicate the controller can actually run, not a vibe.
- Keywords for discovery seeded throughout: magic strings, version numbers, function signatures, transcription, brief, dispatch prompt.

---

## (2) Verification plan before deploying

This is an **edit to an existing skill** — the Iron Law applies. No untested change ships. Edit without testing = delete and start over.

**RED — baseline, confirm the failure exists without my guidance.** I cannot just assume controllers re-type values; I need to watch it. Because this is a shaping failure, I micro-test the wording first (cheap, fast) before committing to full pressure scenarios.

1. **Micro-test setup:** System prompt = the *full current SDD skill* (the realistic context the guidance will live in), NOT my new paragraph in isolation. User message = a controller task with a competing incentive baked in: "Write a dispatch prompt for the implementer; make it self-contained so the subagent isn't blocked." The brief file is provided and contains a pinned version, a magic string, and a function signature.
2. **No-guidance control is mandatory.** If the control *doesn't* re-type exact values, there is no failure to fix — I stop and don't ship the guidance. (This guards against shipping a fix for a problem that isn't real in the model's default behavior.)
3. **5+ reps per variant.** Single samples lie. Variants: (a) control = current skill, (b) my recipe wording, (c) a prohibition-worded version ("never re-type exact values from the spec"). I include the prohibition variant specifically because the skill warns prohibitions backfire on shaping failures — I want to confirm head-to-head that the recipe beats it rather than trusting the principle blindly.
4. **Read every flagged match manually.** Automated grep for version strings / the magic string will false-positive on (a) the controller quoting the *path* to the value and (b) pointer phrasing that names a brief section. I score by hand: did the literal value appear, or only a pointer to it?
5. **Variance is a metric.** If the recipe variant's 5 reps converge on "brief path + pointers," the form is binding. If they scatter — some pointing, some restating, some half-and-half — the wording isn't tight enough and I revise the form before adding words.

**GREEN — the recipe variant should produce pointer-only prompts** across reps, while the control restates values. **REFACTOR** — if a new rationalization shows up (e.g., "I'll inline it AND point to it, to be safe"), I add a counter, but as a tightening of the recipe, not a new prohibition.

**Final gate:** micro-tests verify wording only. For the deployed change I run it as a real dispatch in an actual SDD controller turn to confirm the recipe survives a full task context, then commit and push.

**One caveat I'd flag to you:** if baseline (RED) shows controllers *don't* actually re-type values when the skill already names the brief as source of truth, then the real fix may be elsewhere (e.g., briefs aren't reliably created, or controllers don't know the brief exists) — and I'd redirect rather than ship this paragraph.