user-invocable: false is ignored by the per-plugin browser menu

Bug: user-invocable: false is ignored by the per-plugin browser menu

Component: Claude Code — slash-command / plugin UI
CC version: 2.1.168 (Windows 11, native install)
Severity: Low (clutter / UX), but persistent and confusing for plugin authors

Summary

Setting user-invocable: false in a plugin skill's SKILL.md frontmatter correctly
hides the skill from the top-level / typeahead and from /skills — but the nested
per-plugin browser menu (open the / menu → expand a plugin, e.g. "My Plugin ›")
still lists every skill, regardless of the flag.

The result: a plugin that deliberately exposes only a handful of curated commands still
shows its entire internal skill set in that browser, with no author-side way to suppress
them.

Expected behaviour

A skill with user-invocable: false should be hidden from all user-facing
command-selection menus — including the per-plugin browser — while remaining
model-invocable. (Per the docs, the flag's purpose is "hidden from the menu, still
Claude-invocable.")

Actual behaviour

• ✅ Hidden from the top-level / typeahead.
• ✅ Hidden from /skills.
• ❌ Still listed in the per-plugin browser (the menu with "Manage plugins /

Add plugin" in its footer). Every internal skill appears there alongside the
curated commands.

Reproduction

1. Install a plugin that ships, say, 8 commands/*.md (curated) and 20

skills/<name>/SKILL.md, where every skill has user-invocable: false.

1. Open the / menu and expand the plugin's submenu (the plugin browser).
2. Observe: all 20 internal skills are listed, despite the flag.

Concrete case: plugin soca-stack (v0.33.0 installed). All 20 pipeline skills carry
user-invocable: false (verified on disk in
~/.claude/plugins/cache/.../soca-stack/0.33.0/skills/*/SKILL.md). They are correctly
absent from the / typeahead but fully listed in the per-plugin browser.

Why a workaround isn't available

The author needs "hidden from menu, still model-invocable" (the skills are invoked
by the orchestrator mid-pipeline). The documented alternatives don't fit:

• disable-model-invocation: true — does NOT hide from menus, and blocks the model

(the opposite of what's needed).

• skillOverrides: "off" in settings — hides them but also removes them from the

model's context, breaking the pipeline.

So there is no author-side or settings-side mechanism to keep these out of the
per-plugin browser. This appears to be undocumented UI behaviour: the browser
enumerates a plugin's full component inventory rather than applying the same
visibility filter as the / typeahead.

Suggested fix

Make the per-plugin browser honour user-invocable: false the same way the /
typeahead and /skills already do.

Docs reference

user-invocable is documented under "Control who invokes a skill"
(code.claude.com/docs/en/skills.md). The docs describe it as affecting "the / menu"
but do not mention the per-plugin browser — which is the surface where it currently
fails to apply.