I'll start by classifying the failure before reaching for a fix — the writing-skills rules make the form depend on the failure type.

## Classifying the failure

The Model Selection section already exists and explains *how to choose*. The problem isn't that controllers don't understand model selection — it's that they **omit a required element from something they already produce** (the dispatch call). That's not a discipline failure under pressure, and it's not a wrong-shape problem. It's an omission.

Per *Match the Form to the Failure*:

| Baseline failure | Right form | Wrong form |
|---|---|---|
| Omits a required element from something they already produce | **Structural: REQUIRED field/slot in the template they fill in** | Prose reminders near the template |

So the fix is **not** more prose in the Model Selection section, not a rationalization table, not a red-flags list. It's making `model` a structural slot in the dispatch template itself, so omitting it is omitting a visibly-empty field rather than forgetting an instruction.

But I haven't earned the right to write *anything* yet.

## The Iron Law applies — including to edits

> NO SKILL WITHOUT A FAILING TEST FIRST. This applies to NEW skills AND EDITS to existing skills.

I have a *report* of omissions, but I haven't watched the baseline fail, and I don't yet know *why* controllers omit it. Until I run the baseline I can't tell apart:

- The dispatch template has no `model` slot → they fill in the slots that exist (structural fix).
- The template has a slot but it's optional/easy to skip (make it REQUIRED).
- The Model Selection section is in a part of the skill controllers never read at dispatch time (move it adjacent to the template).

These need different fixes. Guessing violates the law. So:

---

## (1) The exact change I would make

**I would not commit any change until the baseline run tells me which of the above is true.** What follows is my *candidate* change, contingent on the baseline confirming the template lacks a required slot (the most likely case given the symptom).

In the dispatch template inside the SDD skill, make `model` a required, visibly-empty slot the controller must fill — and key the default to an observable predicate rather than leaving it implicit:

```diff
 Dispatch a subagent with:
 - description: <one-line task summary>
 - prompt: <full task brief>
+- model: <REQUIRED — choose per Model Selection above; if unsure, set "sonnet">
```

Rationale, tied to the writing-skills rules:
- **Structural, not prose.** The slot lives in the template they already fill in, so omission becomes a blank `<REQUIRED ...>` rather than a forgotten instruction.
- **Conditional keyed to an observable predicate.** "if unsure, set sonnet" replaces the silent inherit-most-expensive default with a safe, explicit fallback — no exemption clauses.
- **No new prohibition.** The Model Selection section stays as the *how-to-choose* reference; I cross-reference it ("per Model Selection above") instead of duplicating it.

If the baseline instead shows the slot exists but is skipped, the change becomes "mark the existing slot REQUIRED + add the unsure-default." If it shows the section is too far from the template, the change is to move/co-locate it. Same structural family, different exact edit.

## (2) Verification plan before deploying

**RED — establish the baseline (do this first, no edit yet):**
1. Read the current SDD skill to confirm whether the dispatch template has a `model` slot at all. The actual code drives which candidate change is correct.
2. Micro-test the *omission*, with the realistic context as system prompt:
   - System prompt = the current SDD skill text (unedited).
   - User message = a task that tempts cheap-model-eligible work dispatched to a subagent.
   - **5+ reps**, plus a **no-guidance control** (SDD skill with the Model Selection section stripped). If the control omits `model` no more than the current skill does, the existing section isn't doing anything and I confirm omission is the real failure mode. If the control behaves identically to full skill — the section was never the lever; the template is.
   - **Read every transcript manually** — a controller that *mentions* model in prose but never sets the parameter is still an omission; automated "found the word model" counts would falsely pass it.
3. Record the omission rate and *why* each rep omitted (no slot / skipped slot / never saw the section).

**GREEN — apply the matched change and re-test:**
4. Make the change the baseline pointed to (candidate above if template lacks the slot).
5. Re-run the same 5+ reps with the edited skill. Success criterion: every rep sets `model` explicitly, and unsure cases fall back to the stated default rather than inheriting.
6. **Variance check:** reps should converge on the same dispatch shape. If they still vary in whether/how they set `model`, the slot wording isn't binding — tighten the structural form before adding any prose.

**REFACTOR:**
7. Add a counter-eligible task (one where the cheap model would be *wrong*) to confirm the `<REQUIRED>` slot doesn't push controllers into blindly defaulting to sonnet for work that needs more.
8. Only after wording micro-tests pass, run a full dispatch pressure scenario as the final gate.

**Deploy:** commit and push only after GREEN holds across reps.

---

**Bottom line:** I won't write the fix as more explanation in Model Selection — that's prose-reminder treatment for an omission, the explicitly-wrong form. The fix is a REQUIRED structural slot with an observable-predicate default, and I gate it behind a baseline run that confirms which structural variant the actual skill needs.