Before I write anything, let me classify this against the Iron Law and "Match the Form to the Failure" — because the form I pick determines whether this guidance helps or backfires.

## Classifying the failure

This is **not a discipline failure**. The controller isn't knowingly skipping a rule under pressure. The dispatch prompt has the *wrong shape*: it contains re-typed exact values that should be references to the brief. That's a shaping problem.

Per the writing-skills table:

| Baseline failure | Right form |
|---|---|
| Complies, but output has the wrong shape (restated spec, duplicated values) | Positive recipe / contract: state what the output IS |

The wrong move here would be a prohibition: "Never re-type exact values from the spec. Don't transcribe magic strings, version numbers, or signatures." Testing in the writing-skills training shows prohibitions backfire on shaping problems — under the competing incentive ("make the prompt self-contained so the subagent has everything"), agents negotiate with "don't X" and produce *more* of the unwanted content. There's also a real condition here (the values live in a brief file the subagent reads), so the guidance should be a **conditional keyed to an observable predicate**, not an unconditional ban.

So: a positive recipe stating what a dispatch prompt's value-handling IS, keyed to "the brief exists."

**I have NOT tested this wording yet, so the text below is a candidate, not a deployable skill.** Per the Iron Law, no skill edit ships without a failing test first.

## (1) Candidate guidance text

```markdown
## Referencing exact values in dispatch prompts

The per-task brief is the single source of truth for exact values. A dispatch
prompt POINTS at those values; it does not reproduce them.

When a task involves a specific value — a magic string, version number,
function signature, file path, error code, or config key — the dispatch
prompt names the value and cites where the subagent reads it:

> "Implement the retry wrapper using the timeout and backoff values defined
> for this task in the brief. Match the exact function signature given there."

NOT:

> "Implement the retry wrapper with timeout=30000, backoff_factor=2.0, and
> signature `retry(fn: Callable, max_attempts: int = 3) -> Result`."

The subagent reads the brief. If the prompt and the brief disagree, the
subagent has two sources of truth and no way to know which is wrong — and
a re-typed value is exactly how they come to disagree.

If a value does NOT appear in the brief, that's a gap in the brief. Add it
to the brief, then reference it. Do not patch the gap by typing the value
into the prompt.
```

This is a recipe (states what the prompt IS), conditional on the observable predicate (the value lives in the brief), with the one real exception expressed as its own conditional (value missing → fix the brief, not the prompt) rather than a nuance clause that reopens negotiation.

## (2) Verification plan

**RED — baseline, before writing anything final:**
1. Micro-test the failure with a no-guidance control. System prompt = the current SDD skill as it actually exists. User message = a realistic controller task whose brief contains a magic string, a version pin, and a function signature, asking the controller to write the dispatch prompt. 5+ reps.
2. Read every output manually. Confirm controllers actually re-type exact values into the prompt. **If the control doesn't exhibit re-typing, stop — there's nothing to fix and no skill to add.**
3. Record verbatim what they type and any reasoning ("so the subagent has it inline," "to be self-contained") — this tells me which incentive the recipe must out-compete.

**GREEN — micro-test the wording:**
4. Run three variants, 5+ reps each, same system context, same tempting task:
   - **Control:** no guidance.
   - **Prohibition:** "Never re-type exact values…" (the form I'm rejecting) — included specifically to confirm head-to-head that it scores *no better or worse* than control on a shaping problem, so I'm not rejecting it on theory alone.
   - **Recipe:** the candidate text above.
5. Score: count prompts that reproduce an exact value vs. reference the brief. Read every flagged match by hand — a prompt that *quotes the brief filename* is a pass, not a re-type, and naive matching would miss that.
6. **Variance check:** recipe reps should converge on the same shape (name + cite brief). If five reps produce five different interpretations, the recipe isn't binding — tighten it before proceeding.

**REFACTOR:**
7. If the recipe leaks (controller references the brief AND inlines the value "just in case"), that's a new shape to close — likely by sharpening the contract, not by adding a "don't also inline it" prohibition.

**Final gate — pressure scenario:**
8. SDD controllers operate under a self-contained-prompt incentive, so run a full pressure scenario stacking that incentive (subagent has limited context + "make sure the implementer has everything it needs") to confirm the recipe holds when the competing pull is strongest. Micro-tests verify wording; they don't replace this.

Only after the recipe beats control AND prohibition, converges across reps, and survives the pressure scenario do I commit the edit.