Before I write any guidance, let me classify the failure against the writing-skills framework — because that classification determines the *form* of the guidance, and getting it wrong measurably backfires.

## Classifying the failure

The controllers re-type exact values into dispatch prompts. There are two possible readings:

- **Discipline failure:** controllers know they shouldn't re-type and do it anyway under pressure → prohibition + rationalization table.
- **Wrong-shaped output:** controllers fill the dispatch prompt and the default mental model is "make the prompt self-contained," so they pull exact values in → the output has the wrong shape.

This is the second one. Controllers aren't violating a known rule under pressure; they're producing a prompt whose default shape includes restated values, because "a good prompt gives the subagent everything." That's a **shaping problem**.

Per *Match the Form to the Failure*: prohibitions backfire on shaping problems. "Never re-type exact values" under the competing incentive of "make the prompt complete" reopens negotiation and can produce *more* restated content than no guidance at all. There's also a clean structural fact here: the exact values **already live in the brief the subagent reads**. So the right form is a **positive recipe / contract keyed to an observable predicate** (the brief file exists and the subagent reads it).

I'll write the guidance as a contract on what a dispatch prompt *is*, with a conditional anchored to the brief, not a prohibition.

---

## (1) Exact guidance text to add

```markdown
## Dispatch prompts reference the brief; they do not restate it

Each task has a brief file the subagent reads before starting. The brief is the
single source of truth for exact values: magic strings, version numbers,
function signatures, file paths, config keys, IDs.

**A dispatch prompt is made of three parts, in order:**

1. **Pointer** — the path to the brief file the subagent must read first.
2. **Task framing** — what to build and why, in your own words (no exact values).
3. **Pointers to specifics** — *where in the brief* each exact value lives
   ("use the signature in the brief's API section"), not the value itself.

If the brief contains the exact value, the dispatch prompt names its location in
the brief. The controller does not type the value.

**The controller types an exact value into a dispatch prompt only when that value
does not exist anywhere in the brief.** When that happens, the value is missing
from the source of truth: add it to the brief first, then point at it. The
dispatch prompt is never the place a value appears for the first time.

### Example

Brief (`tasks/03-rate-limiter/brief.md`) already contains:
> Signature: `def check_limit(user_id: str, window_s: int = 60) -> bool`
> Redis key prefix: `rl:v2:`

❌ Dispatch prompt that restates (transcription risk):
> Implement `check_limit(user_id: str, window_s: int = 60) -> bool`.
> Use Redis keys prefixed with `rl:v2:`.

✅ Dispatch prompt that references:
> Read `tasks/03-rate-limiter/brief.md` first.
> Implement the rate limiter using the signature and Redis key prefix defined in
> the brief. Match them exactly as written there.

### Self-check before dispatching

Scan the dispatch prompt for any literal value — a quoted string, a number, a
signature, a path. For each one, ask: **is this value also in the brief?**
- Yes → replace it with a pointer to the brief's location.
- No → it belongs in the brief. Add it there, then point at it.
```

Notes on form choices, tied to the framework:

- **It's a recipe, not a prohibition.** "A dispatch prompt is made of three parts, in order" states what the output *is*. Nothing to negotiate: the prompt has the three parts or it doesn't.
- **The one allowance is a conditional on an observable predicate** ("does not exist anywhere in the brief"), not a nuance clause. It resolves to a structural action (add to brief, then point) rather than reopening "unless it matters."
- **No exemption clauses.** I don't say "this doesn't apply to small values" — that would still suppress the behavior I want while leaking restatement back in.
- **Self-check is a positive procedure** (scan, classify each literal), not a red-flags-STOP list, because this isn't discipline-under-pressure.

---

## (2) Verification plan before deploying

This is an **edit to an existing skill**, so the Iron Law applies: no change without a failing test first. I micro-test the wording before any full pressure run.

**RED — baseline, no-guidance control (mandatory).** Build a realistic system prompt = the current SDD skill *minus* this section, plus a representative brief file containing several exact values (signature, version, magic string, key prefix). User message = "Write the dispatch prompt for this task." Run 5+ reps. Read every output manually. Confirm controllers actually restate exact values. **If the control doesn't exhibit restatement, stop — there's nothing to fix and the guidance shouldn't be added.**

**Micro-test the wording (5+ reps each, read every match by hand):**
- **Variant A:** my recipe text above.
- **Variant B (the form I'm betting against):** a prohibition — "Never re-type exact values from the brief into dispatch prompts." Run head-to-head against A and the control. I expect B to do no better than (possibly worse than) the control; this validates the form choice rather than assuming it.
- Score each output: (a) count literal values in the prompt and check each against the brief — a restated value present in the brief is a failure; (b) verify the brief pointer is present. **Manually read every flagged literal** — template echoes, quoted counter-examples from my own example block, and pointers like `rl:v2:`-the-location vs `rl:v2:`-the-value will fool a regex count.
- **Variance check:** across the 5 reps of Variant A, do prompts converge on the three-part shape? Five different interpretations = wording not binding → tighten before adding words.

**Edge-case micro-tests:**
- **Value genuinely absent from brief:** brief omits one needed value. Does the controller add it to the brief and point, or silently type it into the prompt? Tests the conditional resolves correctly.
- **Mixed prompt:** some values in brief, some not. Does the controller split correctly rather than restating all?

**GREEN — full pressure scenario** (only after wording converges): run the real SDD controller flow with time pressure and a large brief, confirm controllers reference rather than restate, and confirm subagents still get everything they need (the prompt isn't so thin it's unusable).

**REFACTOR:** capture any new failure modes (e.g., controllers pointing vaguely — "see the brief" without naming the section, defeating the point) and tighten the "where in the brief" requirement. Re-test until convergent.

**Deploy** only after A beats the control on restatement rate with low variance, and the absent-value edge case resolves to "add to brief, then point." Then commit and push.

I will not keep the drafted text if I skip the baseline — if the no-guidance control doesn't restate values, this section gets deleted, not deployed on confidence.