Description:
Currently, when a skill’s frontmatter has disable-model-invocation: true, the Skill tool is completely blocked from activating that skill — even when the user explicitly invokes it via [@skill-name] in the prompt. This is an all-or-nothing approach that breaks skills designed as “user-invoked only.”
Problem:
Skill authors (such as the Matt Pocock skill collection) intentionally mark certain skills as user-invoked only — e.g. /grill-me, /handoff, /teach, /to-questionnaire, /wait-what. The design intent is: the model should not auto-trigger these on its own, but the user should be able to invoke them explicitly.
Under the current behavior:
User types [@grill-me] → 
Skill “grill-me” cannot be activated via the Skill tool due to disable-model-invocation
User types [@ask-matt] → same error
The only workaround is to delete the disable-model-invocation field entirely, which removes the safety guardrail the author intended
Comparison with Codex:
Codex implements the same intent via policy.allow_implicit_invocation: false in agents/openai.yaml, which:
Blocks model-initiated (implicit) calls — the model cannot auto-select the skill
Allows user-initiated (explicit) calls — [@skill-name] still works
Qoder’s disable-model-invocation: true achieves the first goal but breaks the second.
Expected behavior:
When a user explicitly triggers a skill (via [@skill-name] or / syntax), it should bypass the disable-model-invocation flag and activate normally. The flag should only prevent the model from auto-selecting that skill based on its own judgment of context.
Why this matters:
Without this distinction, skill authors are forced to choose:
Keep the flag → the skill is completely unusable in Qoder (even when manually invoked)
Remove the flag → the skill works but the model may auto-trigger it inappropriately
Neither option respects the author’s original intent. This makes cross-platform skill collections (designed for both Claude Code and Codex) incompatible with Qoder.