[Feature]: `disable-model-invocation` flag for skills in `SKILL.md`

[xzavrel]

Problem statement

Every enabled skill has its SKILL.md content injected into the system prompt on every turn of every conversation, regardless of whether the skill is relevant to that conversation.

With 101 bundled skills now shipped by default (PR #797), a user who has several skills enabled accumulates significant token overhead even in conversations where those skills are never used. There is currently no way to keep a skill available for on-demand invocation (e.g. via a slash command) without paying the token cost of having it in the system prompt at all times.

Proposed solution

Add a disable-model-invocation boolean flag to SKILL.md frontmatter:

---
name: my-skill
description: Runs a complex workflow, only needed occasionally
disable-model-invocation: true
---

When disable-model-invocation: true:

• The skill is excluded from the system prompt — zero token cost per turn.
• It remains available as a user-triggered slash command (/my-skill).
• The model never sees it passively; it is only injected into context for the turn when the user explicitly invokes it.

Implementation scope

• crates/skills/src/types.rs — add disable_model_invocation: bool to SkillMetadata (default false)
• crates/agents/src/prompt/builder.rs — skip skills with disable_model_invocation = true in append_skills_section
• Slash command palette — skills with this flag still appear and remain invocable by the user
• On invocation, the skill's content is injected into context for that turn only

Alternatives considered

• Globally disabling the skill — [skills] enabled = false in the manifest (PR fix(chat): honor [skills] enabled=false at runtime #663) disables the skill entirely, including slash commands. Not a viable option for skills you want available on demand.
• registry_mode = "lazy" for tools — moltis already has this for MCP tools, which replaces all tool schemas with a single tool_search meta-tool. There is no equivalent mechanism for skills.
• Writing short skill descriptions — keeping SKILL.md minimal reduces per-skill overhead but doesn't eliminate it, and limits the skill's effectiveness when used.

Category

Agent loop / LLM providers

Priority

Medium — would be very helpful

Additional context

This feature is already implemented in OpenClaw (the upstream reference implementation) under the same disable-model-invocation frontmatter key. The proposed flag name is intentionally identical for compatibility with skills authored for OpenClaw.

From the OpenClaw docs:

disable-model-invocation — true|false (default: false). When true, the skill is excluded from the model prompt (still available via user invocation).

The analogous token-saving feature for MCP tools (registry_mode = "lazy", which replaces all schemas with a tool_search meta-tool) already exists in moltis, making this a natural complement for skills.

[dmitriikeler]

Perhaps it would be better to enable hiding skills from system prompt, while still allowing the model to execute the skill when using read_skill tool with the right VERBATIM name? This could be extremely useful for skills only invoked by cron jobs, for example, or skills that are used extremely infrequently but still pollute the system prompt.

[xzavrel]

Good point on the model-invocable angle — but there's a bootstrapping problem: for the model to call read_skill with the right verbatim name, it needs to know that name from somewhere. Without a discovery mechanism (something like the tool_search meta-tool that registry_mode = "lazy" uses for MCP), the model can't reliably find hidden skills on its own. That would just shift the token cost to a different place (e.g. a skills index injected into every prompt).

I think the model-invocable hidden skill idea is genuinely interesting as a separate concern — maybe something like disable-model-invocation: true combined with a future model-invocable: true flag, backed by a skill_search meta-tool similar to the MCP equivalent.

One related direction I'd also find useful: scoping which skills are active per agent. Right now everything enabled globally is visible to every agent, which multiplies token overhead for agents that only need a narrow set of tools. Per-agent skill filtering would complement this flag nicely — you'd get coarse-grained control at the agent level and fine-grained control at the individual skill level.