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

[grammy-jiang]

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).

[grammy-jiang]

Additional evidence: this looks like a regression in the CLI, not intended semantics — and it contradicts documentation and code that GitHub itself ships.

1. The shipped docs specify the opposite

GitHub.copilot-chat 0.48.1 bundles extension/assets/prompts/skills/agent-customization/references/skills.md, which contains this table:

Configuration	Slash command	Auto-loaded
Default (both omitted)	Yes	Yes
user-invocable: false	No	Yes
disable-model-invocation: true	Yes	No
Both set	No	No

So disable-model-invocation: true is documented to keep the skill reachable as a slash command while removing it from automatic loading. That is exactly the behaviour the CLI does not provide.

2. The SDK implements it correctly

@github/copilot 1.0.39 (the version bundled in that same extension) builds the skill tool like this — minified, reformatted for readability:

function Q4o(t, e) { return e.find(r => r.name === t) }

let g = I.filter(y => !n.has(y.name));             // all discovered skills, minus user-disabled
let f = g.filter(y => !y.disableModelInvocation);  // model-invocable subset
let b = Oxr(f);                                    // tool DESCRIPTION lists only f

return {
  description: d ? xxr : b,
  callback: async y => {
    if (n.has(y.skill)) return { error: `Skill disabled: ${y.skill}` };
    let G = Q4o(y.skill, g);                       // <-- resolution against g, NOT f
    if (!G) return { error: `Skill not found: ${y.skill}` };
    ...
  }
}

The disableModelInvocation filter shapes only what the model is told exists. Resolution goes through g, the unfiltered list, so a skill carrying the flag is still loadable when the user names it. That matches the documented table.

3. The CLI at 1.0.79 returns not-found instead

Same skill, same directory, reported in the original description: ✗ skill(socratic-method) Skill not found: socratic-method, while copilot skill list still shows it under Project skills. The not-found branch means resolution failed, which under the 1.0.39 logic should be impossible for a discovered skill.

I could not diff 1.0.79 directly: from ~1.0.65 the npm package is a loader stub and the JS lives inside the compiled binary, so the code path is no longer statically inspectable. 1.0.55/1.0.60 still ship sdk/index.js but no longer contain the Skill not found string, so the message was reworded somewhere in between — which is roughly where the behaviour seems to have moved too.

Why it matters

The failure is silent in every place a user would check: the skill installs fine, copilot skill list shows it, and any installer's status check reports it healthy. It only fails at the moment of use. Portable skills published for multiple agents carry this field precisely to get manual-only behaviour, so on the CLI they are dead on arrival with no signal.

Happy to test a fix against the original reproduction.