Plugin skills don't support `disable-model-invocation` like user skills do
Summary
User-defined skills support disable-model-invocation: true in YAML frontmatter to hide them from the model's auto-detection. Plugin-defined skills lack this capability, forcing all plugin skills into context regardless of relevance.
Environment
- Claude Code version: 2.1.29
- OS: Arch Linux 6.18.3
The Problem
User Skills (works)
# ~/.claude/skills/my-skill/SKILL.md
---
name: my-skill
description: Does something specific
disable-model-invocation: true
---
Result: Skill hidden from model, only invokable via /my-skill
Plugin Skills (doesn't work)
# ~/.claude/plugins/my-plugin/skills/my-skill/SKILL.md
---
name: my-skill
description: Does something specific
disable-model-invocation: true # ← Ignored
---
Result: Skill still appears in context, disable-model-invocation has no effect
Context Overhead
From /context command with several plugins installed:
| Source | Tokens |
|--------|--------|
| Plugin skills | ~2,000 |
| Plugin agents | ~2,400 |
| Total plugin overhead | ~4,400 |
This overhead is included in every request, with no way to reduce it short of disabling entire plugins.
Impact
- Can't create "manual-only" plugin skills (invoked via
/skill-nameonly) - Plugin authors can't optimize context usage for their users
- Users must choose between plugin functionality and context efficiency
Expected Behavior
disable-model-invocation: true should work identically for:
- User skills in
~/.claude/skills/ - Plugin skills in
~/.claude/plugins/*/skills/
Proposed Solution
- Parse
disable-model-invocationfrom plugin skill frontmatter - Exclude matching skills from model context
- Keep skills invokable via
/plugin:skill-namesyntax
Workaround
Currently none. Users must either:
- Accept the context overhead, or
- Disable the entire plugin
Skill Index Pattern (partial workaround)
Create one auto-detect skill that lists all others:
- 1 skill in context (~26 tokens) vs 20+ skills (~2K tokens)
- Other skills invoked manually via
/skill-name
This requires plugin authors to restructure their plugins.
---
Token Impact
Per-Request Overhead
This overhead is included in every request, not just when using plugins:
| Requests/Session | Plugin Overhead | With disable-model-invocation* |
|-----------------|-----------------|----------------------------------|
| 10 | 44K tokens | ~11K tokens |
| 50 | 220K tokens | ~55K tokens |
| 100 | 440K tokens | ~110K tokens |
*Assuming 75% of plugin skills marked as manual-only
Monthly Cost at Scale
| Sessions/Month | Current Overhead | Optimized | Savings |
|----------------|------------------|-----------|---------|
| 100 | ~$66 | ~$17 | $49 |
| 500 | ~$330 | ~$83 | $247 |
| 1000 | ~$660 | ~$165 | $495 |
(Based on Sonnet input pricing: $3/1M tokens)
---
Related Issues
- #22335 - LSP plugins spawn eagerly regardless of file types
- #22344 - Subagent system prompt bloat
- #13605 - Custom plugin subagents cannot access MCP tools
This issue has 11 comments on GitHub. Read the full discussion on GitHub ↗