[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. Copilot CLI has this and since migrating to Claude Code CLI, I am missing it.

Currently, I added a permissions entry inside ~/.claude/settings.json:

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