[BUG] Skill commands are autocompleted and highlighted mid-sentence, but silently do nothing

Summary

A skill command placed anywhere other than the start of a message is not invoked. But the
UI gives two strong signals that it was recognised: autocomplete offers and inserts the
skill name mid-sentence, and the sent message renders the command as a styled blue token.
There is no warning and no error. The model simply answers the surrounding prose as if the
skill had merely been named, and the user has no way to tell the skill never loaded.

Environment

• Claude Code 2.1.220, Desktop App
• Windows 11 Pro 10.0.26100
• Skill: improve-codebase-architecture from the mattpocock-skills plugin

(mattpocock/skills, v1.2.2). Frontmatter sets disable-model-invocation: true, so the
slash command is the only way to invoke it.

Steps to reproduce

1. Install a plugin that provides skills (e.g. mattpocock-skills).
2. Start typing a message that puts the command mid-sentence:

do a high level /impro

1. The autocomplete dropdown appears and offers

mattpocock-skills:improve-codebase-architecture. Accept it.

1. Finish the sentence: ... review and come back with top 3 improvements.
2. Send.

<img width="704" height="104" alt="Image" src="https://github.com/user-attachments/assets/50574a0e-2b86-45d4-9caf-d822e0bfb199" />

Expected

Either:

• the skill is invoked, with the surrounding prose passed as context/arguments; or
• the client tells the user it was not invoked, and why.

Actual

The skill is not invoked. Nothing is loaded, nothing is logged, nothing is surfaced. The
model receives only plain text and responds to the prose.

In our case the model concluded from its (correct) available-skills list that the skill did
not exist — the skill is hidden from model invocation by design, so from the model's side a
mid-sentence mention and a nonexistent skill are indistinguishable. That produced a
confidently wrong answer, and it took three rounds of debugging the plugin manifest and
settings.json before we worked out the command had simply never fired.

Why this matters

It is intuitive to invoke a skill at the point in the prompt where it makes grammatical
sense. Users do not write commands, they write sentences. The natural phrasing is

do a high level /improve-codebase-architecture review and come back with the top 3

not

/improve-codebase-architecture high level, top 3 please

The command is the verb of the sentence, and it belongs where a verb belongs. Requiring it
in first position asks the user to invert their own sentence to suit the parser. That is
unusual: in most chat tools, @mentions, #channels and slash-style tokens resolve
wherever they appear, so first-position-only is a surprising constraint with nothing in the
UI to teach it.

The current behaviour actively trains the wrong instinct, because the client agrees with the
user twice:

1. Autocomplete fires mid-sentence and inserts the full skill name plus a trailing

space. The client helps build a string it will then ignore.

1. The sent message renders the command as a blue token, styled exactly like a

recognised command. (See screenshot.) Post-hoc highlighting or genuine recognition — from
the user's seat it reads as confirmation.

Two affordances say "this is a command." The behaviour says otherwise. The user is only
told they were wrong by the model's answer being subtly off-target, which is the worst
possible feedback channel — it is easy to mistake for the skill having run badly rather
than not at all.

Suggested fixes

In order of preference:

1. Invoke the skill wherever it appears in the message. Treat the rest of the message as

arguments/context. This matches what the UI already promises.

1. If first-position-only is deliberate, make the UI agree with it: suppress autocomplete

when the caret is not at the start of the message, and do not apply command styling to
tokens that will not be invoked.

1. At minimum, warn: render the token in a distinct "not invoked" style, or show a hint

on send — "Skill commands must start the message. Send anyway?"

Fix 2 alone would have prevented this entirely, and is presumably the cheapest.

Relationship to #77795

#77795 reports the same underlying behaviour on a different surface: a /skill-name
reference inside an Agent tool prompt is received as prose and silently no-ops, which is
terminal for disable-model-invocation: true skills. The shared root cause looks like the
same one — *a slash command only resolves in first position of user input; everywhere else
it is inert and nothing says so.*

Filing separately rather than commenting there, because the distinguishing part of this
report has no counterpart in #77795 and implies a different fix site:

| | #77795 | This issue |
|--------------------------|-------------------------------|-------------------------------------|
| Surface | Agent tool prompt (a string) | Primary chat input (typed by a human) |
| Client UI involved | None | Autocomplete + message rendering |
| Likely fix site | Agent tool / prompt handling | Desktop client input + transcript |
| Distinguishing complaint | Reference is inert | The UI says it isn't |

The autocomplete and blue-token behaviours are the substance here, and neither can occur in
an Agent prompt. The cheapest fix — suppress autocomplete and command styling when the caret
isn't at the start of the message — would not be captured by #77795's scope at all.

Happy to have these merged if maintainers see one fix covering both.

Related observation

The plugin settings page lists these as bare /improve-codebase-architecture, while
autocomplete inserts the namespaced mattpocock-skills:improve-codebase-architecture. Both
appear to resolve, so this is cosmetic rather than a second bug — but the inconsistency sent
us down a wrong path while diagnosing, because it looked like a namespacing problem.