[Feature Request] Add ability to disable individual Claude plugin skills

+1000

I strongly support this feature request! 👍

I'm using the commit-commands plugin and have the exact same issue. Here's my specific use case:

Current Problem:

• I only want to use the /commit command for creating atomic commits
• The /commit-push-pr command appears as the first suggestion when I type /commit
• This forces me to press the down arrow every single time just to select the actual /commit command
• This significantly impacts my workflow efficiency

Why I don't want /commit-push-pr:

1. Safety concern: Automatically committing, pushing, AND creating a PR in one command feels too risky for daily use
2. Not frequently needed: PR creation is a deliberate action that doesn't happen with every commit
3. Atomicity principle: I prefer keeping operations atomic - commit, push, and PR should be separate steps that I control
4. PR standards: PRs require proper review, description, and context - they shouldn't be rushed through an automated command

Proposed Solution:
Allow users to disable individual commands within a plugin, perhaps through configuration like:

{
  "plugins": {
    "commit-commands": {
      "disabledCommands": ["commit-push-pr", "clean_gone"]
    }
  }
}

This would give users fine-grained control while keeping the useful parts of plugins active.

The autocomplete ordering issue makes this particularly urgent - having unwanted commands appear first in the suggestion list creates constant friction in the development workflow.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Still occurring, so ping to keep alive. Anthropic don't ever appear to look at any of these issues though so whether there's any point in keeping it alive is debatable :-)

Anthropic, take a look pls

• 1000

++

Strong +1 here as well. A good example is the superpowers set of skills. I don't always want to go through the full-fledged framework it imposes. And it is really cumbersome to always explicitly have to instruct Claude Code to explicitly not use those.

+1

Would also be useful to be able to selectively disable individual LSP from a plugin - could be a separate issue though.

I hade this problem so that's why I built this Mycelium
One of the features is exactly this. creates a symlink of the plugin and it enables or disable enabled different skills, agents and hooks individually.

Hope it helps.

!Image

https://github.com/bytemines/mycelium

+1 for me.
We rarely use all skills so loading all doesn't help.

Until per-skill disable is supported:
Workaround 1 — CLAUDE.md blocklist:

<!-- CLAUDE.md -->
Do not use the following skills: commit-push-pr, clean_gone
Only use the commit skill from commit-commands.

This prevents Claude from invoking the skills you don't want, though they still appear in /skills.
Workaround 2 — PreToolUse hook to block specific skills:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Skill",
        "hook": "bash -c 'INPUT=$(cat); SKILL=$(echo \"$INPUT\" | jq -r \".tool_input.skill // empty\"); BLOCKED=\"commit-push-pr clean_gone\"; for b in $BLOCKED; do [ \"$SKILL\" = \"$b\" ] && echo \"BLOCK: Skill $SKILL is disabled.\" >&2 && exit 2; done'"
      }
    ]
  }
}

This blocks specific skills at the tool level. Claude will see them in the list but can't invoke them.
Workaround 3 — Fork the plugin:
If you want full control, fork the plugin and remove the unwanted skill directories:

git clone <plugin-repo>
rm -rf skills/commit-push-pr skills/clean_gone

Then update extraKnownMarketplaces in settings.json to your fork.

Adding a plugin-author data point: this gap bites the people shipping skills, not only the consumers.

I maintain a plugin (workflow-secretary-suite) that ships ~20 skills as one coherent suite. Every consumer session loads all of those descriptions (~2k tokens) at startup, and there is nothing I can ship — and nothing a consumer can set — that trims it per skill:

• skillOverrides (name-only / user-invocable-only / off) is ignored for plugin skills, under both bare and plugin-namespaced keys. Confirmed by measurement on real installs, and now documented ("Plugin skills are not affected by skillOverrides", skills.md). #76156 traces it to the resolver hard-coding source === "plugin" to "on".
• claude plugin disable is all-or-nothing per plugin.
• disable-model-invocation: true frontmatter does travel with the plugin, but it is the wrong tool for most skills: it removes the skill from model invocation entirely — including dispatch from other skills via the Skill tool — so a suite whose skills invoke each other cannot use it on those, and there is no shipped equivalent of name-only.
• plugin.json silently ignores unknown fields, so nothing can be declared there either (claude plugin validate names skillOverrides and permissions as ignored).

Either direction would resolve it:

1. Honor skillOverrides for plugin skills under namespaced keys (plugin:skill), or
2. A per-skill load level that travels with the plugin (SKILL.md frontmatter or a plugin.json key), e.g. load: name-only.

The workaround available to authors today is splitting one suite into several plugins purely so consumers get coarse on/off granularity — packaging noise standing in for a settings key.

Still reproducible on 2.1.224.

Please consider adding this feature. Currently, I added a permissions entry inside ~/.claude/settings.json:

{
  ...
  "permissions": {
    "deny": [
      "Skill(code-review)",
      "Workflow(code-review)",
      "Skill(...)", 
      "Workflow(...)"
    ]
  }
}

Strong +1 here as well. A good example is the superpowers set of skills. I don't always want to go through the full-fledged framework it imposes. And it is really cumbersome to always explicitly have to instruct Claude Code to explicitly _not_ use those.

This is the exact use case I have. I like some of the superpowers skills, but others I don't want to use and they end up hijacking my workflow.

100%. On the personal front I just gave up on plugins since I really keep most of them internal, and instead I have deploy and enroll wrappers so that I can deploy my stuff to a local directory on the machine, then symlink or inject to cmdline args what I need into the relevant repos' sessions. This applies to MCPs, SKILLS, env vars, everything.

I feel like a lot of folks either work in a differing mode, or the devs build around it themselves, in that they work the same way with the same toolsets and approaches system-wide or run each in completely isolated environments (same thing really). I personally have a "dev box" that is LLM owned and managed and break out a huge number of projects into work trees, sharing a lot of backbone between them such as hypervisor, networking, storage, etc etc, but the projects are literally on every side of the spectrum as far as code, approach, language, and anything else you can imagine go. When I stopped loading "everything" at once I saw a notable improvement in context savings not dragging all of the tools around into unrelated sessions and allows me to avoid tailoring things heavily per-project yet still allowing me to have a customized cherry-picked configuration that is automatically detected/used. Aside from context savings on the tool load side it also stops sessions from getting curious and lets me replace that bloat with useful things instead - I use a custom launch wrapper with logics such as "if this condition is true, or this is loaded and this isnt, if repo starts with the term Donkey, use these extra MCP launch args, re-stage vars, drop symlinks, whatever" which literally replaces negative value crud with high value context and still saves me.

Might be a rant or just my weird ADHD way of working, but sharing in case it helps anyone else or helps improve the harness itself!

Numbers from one real setup, in case they help prioritise this (Claude Code 2.1.280, measured 2026-09-23).

compound-engineering alone puts 27 model-visible skills into every session's skill listing (the listing attachment is about 8.0k characters smaller without it, table below). Over the last 30 days of our sessions, 4 of those 27 were never invoked and 9 more were invoked five times or fewer; the rest carry nearly all the use. We would keep the plugin and hide the tail.

Four headless sessions in scratch projects, comparing the skill_listing attachment each one recorded:

| Project .claude/settings.json | compound-engineering entries | Listing vs control |
|---|---|---|
| none (control) | all present | - |
| {"enabledPlugins": {"compound-engineering@every-marketplace": false}} | none | about 8.0k chars smaller |
| {"skillOverrides": {"compound-engineering:ce-bakeoff": "user-invocable-only"}} | all present | byte-identical |
| {"permissions": {"deny": ["Skill(compound-engineering:ce-bakeoff)"]}} | all present | byte-identical |

So the only lever today is the whole plugin, per project. The smallest change that would cover our case: accept <plugin>:<skill> keys in skillOverrides, with the same four values it already takes for user, claude.ai-synced and bundled skills, at user and project scope.

Any updates about this feature?