Docs: SKILL.md `model:` revert semantics and skill-to-skill inheritance unspecified

Resolved 💬 1 comment Opened Apr 21, 2026 by ahuimanu Closed May 27, 2026

Observed gap

The SKILL.md model: frontmatter field is defined on skills.md as "Model to use when this skill is active", but the docs do not specify the lifecycle of the pin. Three related questions are unanswered across skills.md and sub-agents.md:

  1. Revert semantics. When a skill with model: opus completes, does the session's effective model revert to whatever it was before the skill ran, or does the pin persist for the remainder of the session until an explicit /model change?
  2. Skill-to-skill inheritance. If a second skill runs next and its SKILL.md omits model:, does the main session's "current" model (which may have been changed by a prior skill) apply, or does omission resolve against the operator's session default?
  3. inherit during-skill resolution. For subagents declaring model: inherit, does inherit resolve against the pre-skill main-session model or the during-skill active model? The literal reading of sub-agents.md:256 ("Use the same model as the main conversation") suggests during-skill, but this is not explicit.

Sub-agents.md does authoritatively document subagent precedence (CLAUDE_CODE_SUBAGENT_MODEL > per-invocation model > subagent frontmatter > main conversation's model, lines 259-264). What's missing is the equivalent clarity for skill model: lifecycle.

Why this matters

Governance-heavy projects that use skills to pin specific models for specific operator moments (e.g. Opus for ceremony/attestation, Haiku for cheap status commands) cannot reason about cost posture or model selection without knowing the revert rule. A skill that pins model: opus for a Gate-5 ceremony, if the pin persists session-wide, silently inflates cost for every subsequent unpinned skill in the same session. A defensive workaround (pin every skill explicitly, never omit model:) is only necessary if the revert rule favors persistence — which the docs don't say.

What would close this

Explicit language in skills.md (or a new "Model pin lifecycle" section) covering:

  • Whether a SKILL.md model: pin is scoped to the skill invocation or persists after completion.
  • How omission of model: in a subsequent skill resolves — against pre-skill session model, post-prior-skill model, or some other rule.
  • How model: inherit in a subagent resolves when the parent session is mid-skill with an active pin.

A precedence table in the shape of the existing sub-agents.md:259-264 table would close all three in one pass.

Tracked downstream

Filed in gzkit as https://github.com/ahuimanu/gzkit/issues/264 on 2026-04-20. Operational concern in that project was mitigated by explicit model: pins on ceremony-adjacent skills, but the underlying doctrine gap is upstream.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗