Proposal: Add machine-readable model/model-family targeting to skill frontmatter

Problem

The spec's compatibility field is free text (up to 500 chars in Claude Code) meant for "environment requirements... intended products or system prerequisites." It's advisory only. No host currently parses it to decide whether a skill should trigger for the model that's active, and there's no field intended for that job.

This matters for skill authors who write instructions calibrated to a specific model or model family: a skill written for Opus-tier reasoning gives bad results run verbatim on a lightweight model, and a skill tuned for a particular family's quirks (e.g. how Sonnet handles long tool chains vs how Opus does) doesn't necessarily transfer to a sibling family from the same provider. Today the only workaround is embedding conditional branches in the skill body itself ("if you are model X, do Y"), which depends on the model accurately self-identifying and adds instructions that fire for every model even when only relevant to one.

Separately, Claude Code already has a model: field, but it does something different: it forces which model executes the skill once triggered. It doesn't gate whether the skill is offered to a given model in the first place. That's a real gap for authors who want the opposite: "only surface this skill when the active model belongs to family X" rather than "force model X to run this skill."

Proposal

Add an optional, structured targeting field, separate from the free-text compatibility field, so hosts can filter or de-prioritize skills before they ever reach the model's context, without requiring authors to author per-model conditional logic in the body.

Suggested shape:

---
name: deep-refactor
description: Multi-file refactor planning for large codebases
model-targets:
  - provider: anthropic
    family: [opus, mythos]
  - provider: openai
    family: gpt-5.6
  - provider: openai
    family: gpt-5.6
    model: luna
  - provider: anthropic
    model: claude-sonnet-5
---

Three levels, all optional, independently usable, and combinable in an array. Each entry narrows top-down: provider alone matches every model from that provider, provider + family matches every model in the family, and adding model pins specific models within it.

• provider: vendor namespace (anthropic, openai, google, etc), for hosts that route between providers.
• family: the provider's own product line/series name, not a spec-defined tier. For Anthropic that's names like sonnet, opus, fable, mythos; for OpenAI, a generation like gpt-5.6 or gpt-5.5. Accepts a single value or an array, since an author may want a skill to apply to more than one family from the same provider (e.g. [opus, mythos] for anything reasoning-tier). The spec should not try to enumerate valid family names across providers, since these are product names that differ by vendor and change over time. It should standardize the field name and structure only, and let each provider document its own accepted values, the same way HTTP doesn't enumerate valid User-Agent strings but still standardizes the header.
• model: a specific model within a family, or an exact model ID, as a single value, glob, or array (luna, claude-opus-4-8, [luna, terra]). Some providers name models within a family (gpt-5.6's luna/terra/sol), others distinguish them by versioned IDs; both should match. For authors who want precision below the family level, e.g. a skill written for one model's behavior rather than its whole family's.

Absence of the field means "no restriction," preserving backward compatibility with every existing skill.

Open questions

• Enforcement vs advisory: should this be a hard filter (host refuses to load the skill) or a soft signal (host deprioritizes it in the listing, same way disable-model-invocation is enforced but compatibility isn't)? Advisory-only seems safer for a v1 given how fragmented family naming is across providers and how often it changes.
• Whether this belongs in the six-field portable core or should stay a host-specific extension (as Claude Code's model: field already is), given that stricter distribution paths (Skills API, claude.ai uploads) currently hard-reject unknown fields.
• Naming collision risk with Claude Code's existing model: field; the two need visibly different names given they do different things (targeting vs forcing).
• Should family matching be exact-string or allow a wildcard/prefix form, given families themselves get iterated on (opus 4 vs opus 4.8)?
• Whether bare model without family should be allowed (probably yes, for providers whose model IDs are globally unique like claude-opus-4-8) or whether short intra-family names like luna should require the family key for disambiguation.