I'll work through this following the writing-skills discipline. But first, the Iron Law applies even to edits: **no skill change without a failing test first.** Let me be honest that what I'm giving you is a *candidate* plus a verification plan — not a deployable, verified change.

## First: classify the failure

This is the critical step that determines the form of the guidance.

The controller **already produces the dispatch prompt** and the subagent **already reads the brief**. The controller isn't skipping a rule under pressure — it's putting the *wrong content* into a slot. The exact value gets transcribed when a *reference* to the brief would do.

Per **Match the Form to the Failure**:

| Baseline failure | Right form |
|---|---|
| Output has the wrong shape (re-typed exact value instead of a pointer) | **Positive recipe / conditional keyed to an observable predicate** |
| ~~Skips a rule under pressure~~ | ~~Prohibition + rationalization table~~ — **wrong form here** |

A prohibition ("never re-type exact values from the spec") is the tempting move and the wrong one. Under the competing incentive controllers actually feel — *"make the dispatch prompt self-contained so the implementer has what it needs"* — a prohibition reopens negotiation and measurably backfires. The recipe leaves nothing to negotiate: the prompt either references the brief or it doesn't.

The predicate is observable: **does an exact value already live in the brief?** That keys the conditional.

## (1) Candidate guidance text

> ### Dispatch prompts reference the brief; they don't copy it
>
> Each task has a brief file the implementer reads directly. The brief is the single source of truth for exact values: magic strings, version numbers, function signatures, file paths, config keys, error messages.
>
> **A dispatch prompt names the task and points to the brief. It does not re-state values the brief already contains.**
>
> Write the dispatch prompt as:
> - **Task**: one line naming what to implement
> - **Brief**: the path to the task's brief file
> - **Intent**: what "done" means in your own words — the goal, not the literal values
>
> If you find yourself typing a quoted string, a version number, or a signature into the dispatch prompt, stop: that value lives in the brief. Reference the brief's section instead of reproducing the value.
>
> The implementer reads the brief for exact values. Your job is to point them at the right task, not to relay its contents.

Notes on form:
- It's a **recipe** (Task / Brief / Intent slots), not a list of don'ts.
- The one near-prohibition ("If you find yourself typing a quoted string... stop") is keyed to an **observable predicate** (a quoted string / version / signature appearing in the prompt) and redirects to the recipe rather than just forbidding.
- No nuance or exemption clauses ("unless the value is short...") — those would reopen the negotiation.

## (2) Verification plan (before deploying)

I will not deploy this until it passes. Plan in RED → GREEN order, micro-tests before full scenarios.

**RED — baseline, no guidance (mandatory control):**
1. Construct a realistic system prompt = the current SDD skill *without* this addition. User message = a task whose brief contains several exact values (a magic string, a version, a function signature), asking the controller to produce a dispatch prompt for the implementer.
2. Add the genuine competing incentive that produces the bug: "make sure the implementer has everything it needs to start immediately."
3. Run 5+ reps. **If the control doesn't re-type exact values, there's nothing to fix — stop and don't ship the guidance.** I expect it to, given the reported field bug, but I have to see it.
4. Record verbatim *why* controllers copy values (e.g. "so the prompt is self-contained," "to save the implementer a lookup"). These tell me which incentive the recipe must out-compete.

**GREEN — micro-test the wording (one API call per rep):**
1. Same scenario, system prompt now includes the candidate guidance.
2. 5+ reps. **Read every prompt manually** — automated scans miss that a controller "referenced the brief" in prose while still pasting the signature, and miss brief-path mentions that are quoted counter-examples.
3. Score: did the dispatch prompt contain any exact value the brief already holds?
4. **Variance is a metric.** If the 5 reps converge on the Task/Brief/Intent shape, the recipe is binding. If they diverge — some reference, some still copy, some half-copy — the form isn't tight enough; revise before spending on full runs.

**Head-to-head check (because this is a shaping problem):**
- Run a third variant with prohibition-only wording ("never re-type exact values") against the same scenario. Confirm the recipe scores at least as well — and watch specifically for the prohibition-backfire pattern (prompts that copy *more* while protesting compliance). This guards against me reaching for the wrong form.

**REFACTOR / pressure scenarios (final gate):**
- Vary the brief: very short exact values (a one-word flag), a value that's genuinely ambiguous to reference, a task with no brief value to copy (does the recipe stay quiet rather than forcing references?).
- Combine pressures: time pressure + an implementer that previously "got confused without the value inline."
- Any new rationalization that re-introduces copying → tighten the recipe (not add a prohibition) and re-run.

**Stop condition:** across pressure variants, dispatch prompts reference the brief and contain zero brief-resident exact values, with low cross-rep variance. Only then commit and push.

Want me to actually run the RED baseline so we have the verbatim rationalizations before committing to this wording?