Slash menu fuzzy-matches over skill name+description, not the plugin namespace — a plugin's command can be hidden when you type the plugin's own name

Summary

Typing a plugin's name in the slash menu (e.g. /lazarus) does not reliably list that plugin's commands. The menu appears to fuzzy-match the typed query as a subsequence against each command's name + description, and does not treat the plugin: namespace prefix specially. As a result, a command is shown only if the query's characters appear in order somewhere in its name or description — so a plugin command can be invisible under the very prefix users expect to surface it, while sibling commands appear by coincidence.

Environment

• Claude Code (desktop/CLI), June 2026.
• Plugin: lazarus@cognitivecode (public marketplace https://github.com/CognitiveCodeAI/lazarus).
• Three skills, namespaced lazarus:discover, lazarus:audit, lazarus:repair.

Observed behavior

• Type /laz → menu lists /audit and /repair, but not /discover.
• Type /dis → /discover appears normally.
• So discover is registered and invocable; it's only missing from the /laz (and /lazarus) result set.

Expected behavior

Typing a plugin's namespace (/lazarus, or a prefix like /laz) should list all of that plugin's commands — users reasonably expect /<plugin> to act as a namespace filter.

Root cause (determined by reproduction)

The filter matches the query as a subsequence (chars in order) over name + description, not as a prefix over the plugin: namespace. For query laz (needs l→a→z in order):

| skill | l→a→z present in name+description? | why |
|---|---|---|
| audit | yes | "…useful on legacy… modernization…" |
| repair | yes | "…run locally, stabilize a stack…" |
| discover | no | description contained no z at all |

audit/repair matched /laz only incidentally (their descriptions happen to contain l…a…z). discover's description had no z, so laz/lazarus could never match it. /dis worked because "dis" is a literal substring of the name discover.

Minimal reproduction

1. Install a plugin whose namespace is foo with two skills:

• bar — description contains the letters of foo as a subsequence (e.g. "full output of…").
• baz — description contains NO subsequence of foo.

1. Type /foo. → bar appears, baz does not — despite both being foo: commands.

Live reproduction in a public repo: CognitiveCodeAI/lazarus at tag v0.2.1 exhibits the bug (/laz hides /discover); v0.3.0 only works around it by adding words with the missing letters to the description — a workaround that shouldn't be necessary.

Impact

• A plugin's primary command can be silently undiscoverable via its own name.
• For Lazarus this hid the entry-point skill (discover), breaking the intended discover → repair flow for anyone reaching for the plugin by name.
• Plugin authors can't predict or control this without reverse-engineering the matcher.

Suggested fixes (either or both)

1. Treat the namespace as a first-class filter: when the query matches a plugin: prefix, list all of that plugin's commands.
2. Rank/segment by match quality: prefix matches on name or namespace:name should rank above (and not be excluded by) loose subsequence matches that only hit the description.
3. If subsequence-over-description matching is intended, document it so plugin authors know the description participates in slash-menu filtering.