[Bug]: Grok provider: $skill-name inserted by the composer picker is sent as literal text and never invokes the skill #13457

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Enable the Grok provider with a plugin-installed skill (on this machine the Grok CLI reports 97 skills, including poteto-mode from the pstack plugin).
2. Open a Grok thread in the T3 web client.
3. Type $ in the composer and pick the skill from the picker.
4. Send the message.
5. Compare with the same request typed as /poteto-mode at the start of the message.

Expected behavior

Selecting a skill from the $ picker should invoke that skill, matching the semantics the picker advertises.

Actual behavior

The picker inserts the literal text $skill-name into the message. For the Grok provider T3 never converts it to an invocation, and the Grok CLI does not expand $name in a plain prompt, so the model receives the raw $skill-name string as prose and the skill never loads. The /skill-name form works because the Grok harness expands it.

Impact

Major degradation or frequent failure

Version or commit

T3 0.0.42 (server runtime at ~/.t3/runtime/versions/0.0.42), Grok CLI 1.0.41

Environment

Linux (EC2), T3 web client over loopback, Grok provider, go-muse-spark-1-3 model

Logs or stack traces

The two observations below are from one thread on the same machine.

1. A message beginning /poteto-mode ... reached the model with the skill expanded. The session transcript shows the skill block injected into the user message, and the skill ran.

2. A message beginning $poteto-mode $poteto-mode ... reached the model as literal text. The session transcript shows $poteto-mode as plain prose with no skill block, and the reply treated it as prose.

A second check without T3 rules this out as a harness-side expansion gap rather than a T3-side one:

$ grok -m go-deepseek-v4-1-flash --always-approve --output-format json -p '$poteto-mode reply with the single word hi'

The model's own reasoning in the response: The "$poteto-mode" looks like a trigger phrase that isn't in my skill list. There's no such skill. The literal $poteto-mode string was delivered verbatim to the model.

Workaround

Type the skill as /skill-name at the start of the message. The composer's / menu also offers the skill, and that path invokes it correctly on Grok.

Supporting detail from the 0.0.42 runtime bundle, for whoever triages this.

• The web client inserts the picker selection as `$${e.skill.name} ` into the composer.
• src/provider/Drivers/CursorSkills.ts defines rewriteCursorSkillMentions, and src/provider/Layers/CursorAdapter.ts applies it so $name becomes /name for Cursor sessions. There is no equivalent rewrite for the Grok provider; src/provider/Drivers/GrokSkills.ts only performs discovery via grok inspect --json.
• The Grok provider snapshot does expose these skills to the client (the cached snapshot at ~/.t3/caches/grok.json lists 97 skills including poteto-mode), so the $ picker offers them.

This is the same class of silent downgrade reported for Claude in #7795, which was closed and folded into the provider-agnostic skill model discussion (#6987). Filed as a bug because the concrete Grok behavior is a no-op invocation, not a feature gap.