[BUG] Mid-input slash completion never matches plugin-namespaced skills (plugin:skill), while the position-0 dropdown does

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

In the terminal CLI, the mid-input slash-command completion (the grey inline "ghost" suffix that Tab accepts, i.e. the only completion surface that still works mid-input, see #90102) never fires for skills that come from a plugin, while it works for user skills (~/.claude/skills/) and project skills (.claude/skills/).

Concrete example on one machine, all three skills loaded and invocable:

| Skill | Where it lives | Registered name | /psa- at position 0 (dropdown) | foo /psa- mid-input (ghost text) |
|---|---|---|---|---|
| psa-inbox | ~/.claude/skills/psa-inbox/ | psa-inbox | ✅ listed | ✅ suggested |
| bmad-quick-dev | .claude/skills/bmad-quick-dev/ | bmad-quick-dev | ✅ listed | ✅ suggested |
| psa-sandbox | plugin psa-tools (skills/psa-sandbox/) | psa-tools:psa-sandbox | ✅ listed | ❌ nothing |

So the same plugin skill is discoverable at position 0 but not mid-input, and a user has no way to tell why: the skill clearly exists, and its siblings from ~/.claude/skills complete fine in the same sentence.

Root cause (from reading the bundled JS of 2.1.258). The two surfaces use different matchers:

• Position-0 dropdown: a Fuse index built over commandName, displayName, aliases, description and partKey, where partKey is the name split on /[:_-]/. That is why psa-sandbox finds psa-tools:psa-sandbox.
• Mid-input ghost text: the token after / is located with /[\s…]\/([a-zA-Z0-9._:-]*)$/, candidates are fetched from the same fuzzy search, but then filtered with a strict prefix check:

``js
for (const Se of [ue.metadata.name, ei(ue.metadata)])
if (Se.toLowerCase().startsWith(oe)) { /* suggest */ }
``

where ei(cmd) is cmd.userFacingName?.() ?? cmd.name. For plugin skills both values are the qualified plugin:skill string (plugin skills get no unqualifiedName; only path-scoped skills do), so "psa-tools:psa-sandbox".startsWith("psa-sandbox") is false and the candidate is dropped. Any skill that is not namespaced passes the check, which is exactly the observed split between plugin skills and everything else.

By construction, typing the fully qualified name mid-input (foo /psa-tools:psa-s) should pass the prefix check, but nobody types plugin: first, and the position-0 dropdown teaches users the short form works.

What Should Happen?

Mid-input completion should accept the same query the position-0 dropdown accepts. Either:

• also compare the prefix against the part after the last : (or against the same partKey segments the dropdown uses), or
• populate unqualifiedName for plugin skills and include it in the mid-input prefix check.

Both surfaces should agree on whether /psa-sandbox refers to the plugin skill psa-tools:psa-sandbox.

Error Messages/Logs

None. The token is simply rendered as plain text, no suggestion appears.

Steps to Reproduce

1. Install any plugin that ships a skill, e.g. a marketplace plugin my-plugin with skills/my-skill/SKILL.md (frontmatter name: my-skill). Confirm /context lists it as a plugin skill.
2. Create a user skill with a name that shares a prefix, e.g. ~/.claude/skills/my-other/SKILL.md (name: my-other).
3. Start claude in the terminal, type /my- at position 0. Both /my-other and /my-plugin:my-skill are listed. ✅
4. Clear the input, type please run /my-o. Ghost text completes my-other, Tab accepts it. ✅
5. Clear the input, type please run /my-s. No ghost text, nothing to accept. ❌
6. Type please run /my-plugin:my-s. Ghost text appears (qualified prefix passes the check), confirming the matcher is the difference, not the registry.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

2.1.258 (Claude Code), native binary via ~/.local/bin/claude

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (Ghostty)

Additional Information

• Related but different: #90102 / #90441 / #89720 / #91337 / #89398 are about the dropdown not opening mid-input. This report is about the ghost-text completion that does still run mid-input, and about it silently excluding an entire class of skills.
• Related: #86254 (qualified plugin:skill display feels cluttered). That issue notes unqualified invocation resolves fine; this report shows the mid-input matcher does not share that leniency.
• Reproduced in the terminal CLI (not the desktop app).