The Iron Law applies here: **NO SKILL EDIT WITHOUT A FAILING TEST FIRST.**

You've described a real symptom (transcription errors shipping bugs), which is good evidence the skill has a gap. But I can't write the guidance text first and verify after — that's "code before test." Let me show you the correct order, then give you what you actually asked for in the right sequence.

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

If I write polished guidance now, I'll be guessing at:
- What controllers actually do under pressure (do they re-type because they don't trust the brief? Because they want the prompt "self-contained"? Because they're skimming the brief?)
- Which rationalizations they use ("it's clearer for the subagent if I include it inline")
- Whether my guidance addresses the *real* failure mode or a hypothetical one

I'd be writing production code against imagined tests. So here's the actual deliverable: a RED-phase plan first, then *draft* guidance that I'll only finalize after baseline testing.

## (1) Draft guidance (provisional — subject to revision after RED)

This is my starting hypothesis, NOT deployable text. It addresses the symptom you described:

```markdown
## Referencing Brief Values (Never Re-type Them)

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

**In dispatch prompts, reference these values by location — never transcribe them.**

- ✅ "Use the exact error string defined in §2 of your brief."
- ✅ "Implement the signature specified under 'Target API' in the brief."
- ❌ "Use the error string `ERR_AUTH_4012`." (re-typed = transcription risk)
- ❌ "The function should be `parseConfig(path: string, opts: Opts)`." (re-typed)

**Why:** The subagent already reads the brief. Re-typing a value creates a
second copy that can drift from the source. Every transcribed value is a
chance to ship a typo as a bug.

**Rule of thumb:** If a value appears verbatim in the brief, your prompt
should point AT it, not REPEAT it.
```

I have **low confidence** this is right until baseline testing shows me what controllers actually do.

## (2) Verification plan (this comes BEFORE deploying anything)

**This is a technique skill** (how-to for controllers), so I test for correct application, not just compliance under pressure. But because there's a discipline edge ("don't re-type even when it feels convenient"), I'll add mild pressure scenarios.

### RED — establish baseline WITHOUT the new guidance
1. Give a subagent the *current* SDD skill (unmodified) plus a realistic spec containing several exact values (a magic string, a version pin, a function signature) and a brief file that already contains them.
2. Ask it to act as controller and write a dispatch prompt for an implementer task.
3. Run this 3–5 times with variations. **Document verbatim:**
   - Do they re-type values? Which kinds?
   - *Why* — capture their stated reasoning ("I included it inline so the subagent doesn't have to look it up", "to be safe", etc.)
4. Add pressure variants: time pressure ("quick task"), a value that's long/awkward, a spec where the value is "obviously simple."

If controllers *don't* re-type in baseline, the skill already works and I stop — no edit needed.

### GREEN — write minimal guidance against observed failures
5. Revise the draft above to counter the *actual* rationalizations captured in RED (e.g., if they say "inline is clearer for the subagent," I add an explicit counter).
6. Re-run the same scenarios WITH the guidance. Verify they now reference instead of transcribe.

### REFACTOR — close loopholes
7. Look for new rationalizations ("this value isn't in the brief so I'll add it" — does the brief actually contain it?). Build a small rationalization table if pressure scenarios reveal escape hatches.
8. Re-test until controllers consistently reference values across all variants.

### Deployment
9. Only after GREEN passes under all scenarios: commit and push.

---

**Bottom line:** I'm not deploying the text in (1) until RED shows me it addresses real behavior. Want me to run the baseline scenarios now so we can write the guidance against actual failures rather than my guesses?