disable-model-invocation: true makes a skill unreachable, not manual-only (Skill not found on explicit invocation)

Summary

A project skill whose SKILL.md frontmatter carries disable-model-invocation: true is not reachable from the CLI at all. copilot skill list shows it under Project skills, but the model's skill() tool returns Skill not found: <name>, so an explicit user request for the skill fails too.

In Claude Code (where the field originated) and in Cursor, disable-model-invocation: true means "the model may not select this skill on its own; the user can still invoke it by name". The CLI appears to treat it as "do not expose this skill at all", which leaves no way to run the skill.

Version / environment

• GitHub Copilot CLI 1.0.79
• Linux (Fedora, kernel 7.0.13)
• Skill directory: <repo>/.github/skills/socratic-method/, inside a git repository

Reproduction

Using a published skill that ships the field (socratic-method):

pipx install socratic-method
cd "$(mktemp -d)" && git init -q .
socratic-method setup copilot --copy   # writes .github/skills/socratic-method/

1. The CLI discovers it:

$ copilot skill list
Project skills:
  socratic-method - Interrogates the user's idea with disciplined Socratic questioning until hidden assumptions, ...

2. The model cannot reach it, even when named explicitly:

$ copilot -p 'Use the /socratic-method skill. Before asking me anything, reply with exactly
  one line of JSON: {"loaded": true|false, "path": "<SKILL.md path>"}' --allow-all-tools --no-color

✗ skill(socratic-method) Skill not found: socratic-method

{"loaded": false, "path": ""}

3. Delete the disable-model-invocation: true line from .github/skills/socratic-method/SKILL.md and re-run the same prompt — the skill loads normally:

● skill(socratic-method)

{"loaded": true, "path": "/tmp/tmp.XXXX/.github/skills/socratic-method/SKILL.md"}

Isolation

Same sandbox, same prompt, only the frontmatter differs:

Frontmatter	Result
disable-model-invocation: true + user-invocable: true	Skill not found
disable-model-invocation: true only	Skill not found
neither key	loads normally

disable-model-invocation alone reproduces it; user-invocable is not involved. YAML comments elsewhere in the frontmatter are present in all three cases and are not a factor.

Expected

disable-model-invocation: true should keep the skill out of automatic selection while leaving it invocable when the user names it — matching the semantics of the agent that introduced the field, and matching what the field is for: skills with side effects, or long interactive workflows, that should only run on request.

If the CLI intends different semantics, that is worth documenting. Adding agent skills for GitHub Copilot CLI documents only name, description, license and allowed-tools, so today the behavior is silent: the skill installs fine, lists fine, and only fails at the moment of use.

Impact

Portable skills written against the shared SKILL.md format and published for several agents carry this field to get manual-only behavior wherever it is supported. On the CLI those skills are silently dead — nothing in skill list, in install tooling, or in the docs signals a problem until a user tries to run one.

Related but distinct: #3095 (adding capability declaration fields to frontmatter).

Start from the CLI skill discovery and the model's skill() tool, reproducing the behavior with a SKILL.md containing disable-model-invocation: true. Compare the handling of that field with a skill that omits it, then verify that explicit invocation succeeds while automatic selection remains disabled. Confirm the behavior with the listed reproduction and skill list output.