The Iron Law applies here, including to edits. Let me be precise about what I actually know versus what I'm assuming.

## What I cannot do yet

I cannot give you "the exact change" because **I haven't run the baseline test.** The skill already has a Model Selection section explaining *how to choose* — yet controllers still omit the parameter. That's the critical clue: **explaining how to choose isn't the gap.** Agents apparently understand selection but skip the step entirely under the momentum of dispatching.

Writing a fix now would be writing production code before watching the test fail. I'd be guessing at the rationalization. Let me instead tell you what I'd do, in order.

## RED phase: reproduce the omission (this comes first)

Run 3+ pressure scenarios with subagent controllers, WITHOUT any skill change, capturing verbatim behavior:

1. **Momentum pressure:** "Dispatch a subagent to run the test suite and report failures." (Simple task — does the controller bother specifying a model?)
2. **Multi-dispatch pressure:** A plan with 5 independent tasks dispatched in sequence. (Does specification decay after task 1?)
3. **Authority/ambiguity pressure:** "Just get this refactor done fast." (Does urgency cause omission?)

For each, record:
- Did they include the model param? (yes/no)
- If no, what was the implicit reasoning? Did they even consider it, or was it invisible?
- Did they read the existing Model Selection section at all?

**The likely finding I'm testing for:** the existing section is *reference material on how to choose* — it answers "which model?" but never forces the question "did you specify one?" to arise during dispatch. Selection guidance ≠ a dispatch-time checkpoint. The omission is mechanical, not a judgment failure.

## The crux: is this even a skill problem?

From writing-skills:

> **Don't create for:** Mechanical constraints (if it's enforceable with regex/validation, automate it—save documentation for judgment calls)

If subagents *silently inherit* the expensive model, the real fix may be **changing the default to fail loud or default cheap**, not documenting harder. A dispatch that errors or warns when no model is specified solves this permanently; a paragraph relies on every agent remembering forever.

So my RED phase also answers: **can this be enforced mechanically?** If the dispatch tooling can require an explicit model (or default to the cheap one with an opt-in to expensive), that's the correct fix and no skill edit is warranted.

## GREEN phase: the candidate change (only if it's a judgment gap)

If — and only if — baseline shows agents *correctly choosing* when prompted but *forgetting to act* at dispatch time, the minimal edit is **not** expanding "how to choose." It's adding a dispatch-time trigger. Probable shape:

- A **red-flag line**: "Dispatching without an explicit model? STOP — you're inheriting the session model." 
- A one-line rule placed at the dispatch instruction, not buried in the selection reference.
- Possibly a description-field trigger update so the skill loads at dispatch time.

But I will write the exact wording *against the verbatim rationalizations from RED*, not now.

## Verification plan before deploying

1. Re-run the same 3 scenarios WITH the change. Success = explicit model param every time.
2. **Loophole hunt:** introduce a new pressure (e.g., "the cheap model failed last time, just use a good one") and check whether they now over-specify expensive without justification — overcorrection is also a failure.
3. Iterate REFACTOR until bulletproof across all scenarios.
4. Confirm no regression: a task that genuinely needs the expensive model still gets it with stated reasoning.

## Summary of my answer

1. **The exact change:** I won't fabricate it. First I run baseline to confirm whether this is a mechanical omission (→ fix the tooling/default, no skill edit) or a dispatch-time judgment gap (→ add a dispatch-time red-flag trigger, not more selection guidance). The existing "how to choose" section is almost certainly not where the fix belongs.
2. **Verification plan:** RED baseline first → minimal targeted edit → re-run identical scenarios → loophole/overcorrection hunt → regression check → iterate until bulletproof, then commit.

Want me to run the baseline scenarios now so I can give you the exact wording?