Feature: model field in skill frontmatter for per-phase model routing

Summary

Add an optional model: field to skill frontmatter that tells the Claude Code client to switch the active model when that skill is invoked. This would enable workflow systems to route different phases of work to appropriately-sized models without losing conversation context.

Motivation

Skills already support frontmatter fields (name, description, etc.), and agents support a model: field that controls which model the agent runs on. But skills and agents serve different purposes:

• Agents spawn subprocesses with isolated context
• Skills inject instructions into the main conversation, preserving all loaded context

For users who build multi-phase workflows using skill chains (e.g., audit → design → execute → validate), different phases have very different cognitive demands:

| Phase | Primary work | Ideal model |
|-------|-------------|-------------|
| Business scoping | Reasoning, understanding requirements | Opus |
| Technical audit | Codebase exploration, search | Sonnet/Haiku |
| Design proposal | Complex reasoning, tradeoffs | Opus |
| Execute | Code generation | Sonnet |
| Validate | Running commands, checking output | Sonnet/Haiku |
| Ship | Mechanical git/PR work | Sonnet/Haiku |

Today the only options are:

1. Use agents — but this loses the accumulated context from prior skill invocations, which defeats the purpose of a skill chain
2. Manually run /model between phases — adds friction and requires the user to remember which model fits which phase
3. Stay on one model throughout — overpays for simple phases or under-resources complex ones

Proposed Solution

Allow an optional model field in skill frontmatter:

---
name: dbt-technical-audit
description: Assess current state of dbt models
model: sonnet
---

When the skill is invoked, the client would switch the active model before processing the skill's prompt. Valid values would match the existing model aliases: opus, sonnet, haiku, inherit (default, no switch).

Behavior Details

• If model: is omitted, behavior is unchanged (skill runs on whatever model is currently active)
• The model switch persists for the conversation until another skill with a different model: is invoked, or the user manually runs /model
• This is a client-side routing decision — the skill prompt itself is still injected into the main conversation context as it is today

Use Case

I maintain a multi-phase execution cycle built entirely with skills. Each phase loads domain-specific context (dbt standards, Looker conventions, business rules) into the main conversation via skill invocation. Agents can't replace this because they'd lose that accumulated context. Per-skill model routing would let me optimize cost and latency across phases without sacrificing context continuity.

Alternatives Considered

• Agent model: field: Already exists but spawns isolated subprocesses — not suitable for context-dependent skill chains
• Hooks: Can run shell commands on events but have no mechanism to change the active model
• opusplan: Provides binary plan-vs-execute switching but doesn't map to arbitrary workflow phases