I'll apply the Iron Law before proposing any change.

## The Iron Law Check

**NO SKILL WITHOUT A FAILING TEST FIRST** — this applies to edits too.

You've described a real symptom (controllers omit the model parameter), and there's a hypothesis (the existing Model Selection section explains *how to choose* but doesn't force *specifying at all*). But I have not yet watched an agent fail. Before I touch the skill, I need to confirm:

1. **What** agents actually do at baseline (do they omit silently, or do they reason about it and skip?)
2. **Why** they omit it (forgot it exists? assumed inheritance? thought default was fine?)
3. Whether the fix belongs in documentation at all, or is a **mechanical constraint** better solved by validation.

That last point matters. From my writing-skills training: *"Mechanical constraints (if it's enforceable with regex/validation, automate it—save documentation for judgment calls)."* If dispatch tooling can reject a subagent call that lacks an explicit `model` parameter, that's strictly better than documentation. **I'd flag this question to you before assuming a skill edit is the right tool.**

Assuming we've confirmed it's a judgment/discipline gap (not automatable), here's the plan.

---

## (1) The exact change I would make

**I cannot give you the exact change yet** — I have to run the baseline (RED) first to see the actual rationalizations, and the skill text must address *those specific* failures, not my guesses. Writing the edit before seeing the failure is exactly the violation the Iron Law forbids.

What I *can* commit to now is the **shape** of the change, to be finalized after baseline:

- This is a **discipline-enforcing** problem (controllers must always do X), so the fix is likely a small explicit-requirement addition near the Model Selection section, e.g. a "**Always specify `model` explicitly — never rely on inheritance**" rule plus a rationalization table built from baseline transcripts.
- Possibly a one-line addition to the **description** capturing the violation symptom ("Use when dispatching subagents...") — but only if baseline shows agents aren't reading the section at all (a discovery problem) vs. reading it and skipping the parameter (a compliance problem). The fix differs:
  - **Discovery failure** → strengthen description/keywords.
  - **Compliance failure** → add explicit requirement + close loopholes ("don't inherit," "don't assume default is cheap enough," "don't skip 'just this once'").

The exact wording comes out of REFACTOR, after I see what excuses agents generate.

## (2) Verification plan before deploying

**RED — watch it fail (mandatory, before any edit):**
- Write 3+ pressure scenarios where a controller dispatches subagents (e.g., "you're mid-task, dispatch a subagent to grep the codebase" under time pressure + a session already running an expensive model).
- Run them **with the current skill, unedited**. Capture verbatim: do they specify `model`? If not, what reasoning (or silence) led there?
- Identify the pattern: discovery gap vs. compliance gap.

**GREEN — minimal edit:**
- Write only the text that addresses the observed baseline failures. No speculative additions.
- Re-run the same scenarios with the edited skill. Confirm controllers now specify `model` explicitly.

**REFACTOR — close loopholes:**
- Note any *new* rationalization ("but the default was fine here"). Add an explicit counter. Build the rationalization table from all iterations. Add a red-flags self-check list.
- Re-test until compliant under combined pressure.

**Deploy:** commit and push only after GREEN holds under pressure.

---

**Bottom line:** I won't hand you a finished diff right now, because I haven't watched the failure. Tell me whether dispatch tooling can enforce an explicit `model` parameter mechanically — if so, that beats a skill edit. If not, I'll run the baseline scenarios and bring you the exact wording grounded in what the agents actually do.