The Iron Law applies here, and I need to flag a process violation in how this request is framed before producing output.

## The problem with "just fix it"

You've described a symptom (controllers omit the `model` parameter) and proposed where to put the fix (the existing Model Selection section). But the SDD skill *already* explains how to choose a model, and controllers are *still* omitting it. That's the key data point: **explanation already exists and isn't working.**

This means I don't actually know what the fix is yet. The existing section explains "how to choose" — a judgment-call framing. But agents aren't failing to *choose well*; they're failing to *include the parameter at all*. Those are different failures:

- "How to choose" → judgment skill (which model for which task)
- "Always include the parameter" → discipline/mechanical issue

If the real failure is *omission*, this may not even be a documentation problem. Per writing-skills: **"Mechanical constraints (if it's enforceable with regex/validation, automate it—save documentation for judgment calls)."** A missing required parameter in a dispatch call is exactly the kind of thing that might be better caught by validation than by adding more prose to a skill agents already aren't following.

So I won't write the edit yet. Editing a skill without a failing test first is the same violation as writing one without a test.

## What I'd actually do (RED first)

**1. Run baseline before changing anything.** Dispatch 3–5 subagent controllers through realistic SDD scenarios (with the *current* skill loaded) and watch them omit the model parameter. Capture verbatim:
- Do they read the Model Selection section at all?
- When they omit, is it because they didn't choose, or because the dispatch syntax doesn't make `model` feel required?
- What's their reasoning when asked why they left it out?

This tells me whether the fix is mechanical (automate) or documentation (and if documentation, *what* the actual rationalization is).

**2. Check for the description trap.** A likely culprit: if the skill's description or a workflow summary mentions model selection, agents may treat "I considered the model" as done without emitting the parameter. The writing-skills SDO section documents exactly this failure mode — descriptions summarizing workflow cause agents to follow the summary instead of the body.

## Verification plan (before deploying any change)

Once baseline reveals the real failure mode:

1. **GREEN:** Make the minimal change addressing the *specific* observed rationalizations — not generic "remember the model" prose.
2. Re-run the *same* baseline scenarios with the change present.
3. **Success criterion:** controllers include the `model` parameter under the conditions that previously triggered omission, including under pressure (time, complex task, expensive default already in session).
4. **REFACTOR:** If new rationalizations appear ("I'll let it inherit just this once because the task is trivial"), add explicit counters and re-test until omission stops.
5. If baseline shows the failure is mechanical, **stop and recommend validation** (lint/check on dispatch calls) instead of editing the skill.

## What I need from you

Before I produce "the exact change," I need the baseline. I'd rather show you 5 controllers failing in a specific, observable way than guess at edit text that polishes a section agents are already ignoring.

**Want me to run the baseline scenarios now?** Tell me roughly what an SDD controller dispatch looks like in your setup (the dispatch call shape, what "the session's expensive model" defaults to), and I'll design the pressure scenarios and report verbatim what the subagents do. Then the fix writes itself — and we'll know whether it's even a documentation fix at all.