I need to flag something before doing anything: the Iron Law applies here.

## The Iron Law blocks me from starting with a fix

```
NO SKILL WITHOUT A FAILING TEST FIRST
```

This applies to **edits**, not just new skills. You've described a symptom ("controllers keep omitting the model parameter") but I haven't watched a subagent actually fail in a baseline scenario. Without that, I don't know:

- **Whether the existing Model Selection section is the right place** to fix this, or whether the problem is discovery/triggering, not content.
- **Why** controllers omit it — is it that they don't know the parameter exists? Don't know it defaults to expensive? Think it's optional? Rationalize skipping it under time pressure? Each cause needs a different fix.
- **Whether adding content even helps** — testing might reveal the section already says enough and the real fix is elsewhere (e.g., the dispatch template, or a default).

Writing the edit now would be "writing production code before the failing test." So I won't output a concrete edit yet. Here's the actual plan.

## What I'd do instead

### RED — Reproduce the failure (baseline)

1. Write 3+ pressure scenarios where a controller must dispatch a subagent for a cheap task (e.g., "summarize this file"), under pressures like time ("quick check"), momentum (mid-plan), and ambiguity (task doesn't mention model).
2. Run them **with the current SDD skill loaded, unedited.**
3. Record verbatim: Did they specify a model? What reasoning did they give for omitting it? Did they even read the Model Selection section?

This tells me the root cause. Likely candidates:
- They read the section but treat model as optional → need an explicit *requirement* + red flag.
- They never reach the section → discovery/placement problem.
- They assume a safe default → factual correction needed.

### A mechanical-constraint check first

Per writing-skills: *"if it's enforceable with regex/validation, automate it."* Subagent dispatch omitting a parameter may be exactly this. Before writing prose, I'd ask: **can the dispatch tooling require the model parameter or default it to something cheap?** If yes, that beats any documentation. A skill edit is the wrong tool if a default/validation closes the hole deterministically.

### GREEN — Minimal edit addressing the observed failures

Only after baseline. The edit shape depends on findings, but it would target the *exact* rationalizations seen — e.g., a "model parameter is REQUIRED on every dispatch; omitting it inherits the most expensive model" line plus a red flag entry. I won't guess the wording before I've seen the failure.

### REFACTOR — Re-test, close new loopholes

Re-run the same scenarios with the edit. Capture any new rationalizations, add explicit counters, repeat until subagents specify the model under all pressures.

## Verification plan before deploying

1. **Baseline confirmed failing** — at least one scenario shows omission without the edit.
2. **Same scenarios pass with the edit** — controllers now specify a model under each pressure.
3. **No regression** — model-selection guidance still reads correctly; description unchanged unless triggering was the problem.
4. **Word-count / token check** if SDD is frequently loaded.

## What I need from you

To run RED honestly, share (or let me reconstruct) a real dispatch context that produced the omission. If you'd rather, I can author the baseline scenarios myself and run them — but I won't ship an edit until I've watched the failure.

Want me to proceed by writing and running the baseline scenarios now?