I'm going to push back before drafting anything, because this request violates the Iron Law I work under.

## The problem: no failing test yet

**NO SKILL WITHOUT A FAILING TEST FIRST** — and this applies to edits, not just new skills. You've described a real-world symptom (shipped bugs from transcription errors), which is good evidence the problem exists. But "the problem exists in production" is not the same as "I watched a controller subagent fail in a baseline scenario and documented its exact rationalizations."

If I write the guidance text now, I'd be doing the equivalent of writing production code before the test. I'd be guessing at:
- *Why* controllers re-type values (do they not know the brief exists? Do they think inlining is clearer? Do they distrust the subagent to read the file?)
- *What rationalizations* they'd use when told to stop
- *Whether* a stated rule even changes behavior, or whether controllers comply in the academic case but relapse under pressure

I can't write minimal, targeted guidance until I've seen the baseline. So rather than output finished guidance text, here's the honest version of what you asked for.

## (1) Draft guidance — UNTESTED, do not deploy

I'll write a *candidate* so we have something concrete to test against, but this is a hypothesis, not a deliverable. After baseline testing it will almost certainly change.

> **Reference exact values, never re-type them.** The per-task brief file is the single source of truth for magic strings, version numbers, function signatures, and other exact values. When dispatching, point the implementer at the brief — do not copy exact values into the dispatch prompt.
>
> **Why:** Re-typing exact values introduces transcription errors that ship as bugs. The brief already contains the verbatim values; the subagent reads it.
>
> ❌ "Implement `parseConfig(opts: ConfigOptions, timeout = 3000)` returning `Result<Config>`"
> ✅ "Implement the `parseConfig` function exactly as specified in the brief (signature, defaults, return type are authoritative there)."
>
> **Red flags — STOP if you're about to:**
> - Type a function signature, version number, or magic string into a dispatch prompt
> - Think "it's clearer if I just include the value inline"
> - Think "this one value is simple enough to transcribe safely"

This addresses *imagined* rationalizations. The real ones come from baseline testing.

## (2) Verification plan (this is the actual work)

**RED — baseline, before writing final guidance:**
1. Construct 3+ pressure scenarios where a controller subagent must dispatch a task whose brief contains exact values (a tricky signature, a magic string, a pinned version). Combine pressures: time ("dispatch quickly"), apparent-simplicity ("the value is short"), and helpfulness instinct ("make the prompt self-contained for the implementer").
2. Run them *without* any new guidance. Capture verbatim: do controllers re-type values? What reasons do they give? Does the brief-reading instruction already exist and get ignored?
3. Identify patterns. This tells me whether the fix is "they don't know the brief is authoritative," "they think inlining is helpful," or "they don't trust the subagent" — each needs different text.

**GREEN — minimal guidance:**
4. Rewrite the guidance to counter the *actual* rationalizations observed, not my guesses above.
5. Re-run the same scenarios with the guidance present. Verify controllers now reference the brief.

**REFACTOR — close loopholes:**
6. Look for new rationalizations ("I referenced the brief AND included the value as a convenience"). Add explicit counters. Re-test until bulletproof under combined pressure.

**Guard against the SDO trap:** I will NOT summarize this workflow in the skill's description field. The triggering condition belongs there; the rule belongs in the body.

## What I need from you

Want me to proceed with the RED phase — building and running the baseline scenarios? That's the next real step. The guidance text in (1) is scaffolding to be rewritten, not shipped.