Muse threads cannot run user-only skills: $name is sent as plain text, so read_skill returns disabled-skill #31235

What happened

On a Muse Code thread, I invoke a skill by name in the composer ($grill-me, $to-spec, $wait-what). The composer inserts the name. The model then calls read_skill for that name, and Muse returns code: disabled-skill, message: skill is disabled: <name>. The skill never runs.

All three skills have disable-model-invocation: true in their frontmatter. In Claude Code, that means "only the user can invoke it". Here the user did invoke it, but that signal is lost before it reaches Muse. Skills without that flag load fine in the same session (for example, read_skill for grilling returns status="ok").

Diagnosis

On the Muse path, T3 sends the user's $name as plain text only. Nothing tells Muse that the user named a skill.

• packages/provider-muse/src/server/adapter.ts (prompt and turn/start, ~line 2065 at v0.1.7-nightly.20261103.4138) sends only type: "text" parts. It sends no skill part.
• The model can only try read_skill itself, and Muse refuses that for a user-only skill.
• The Claude path rewrites the mention into a real /name invocation (planClaudeSkillDispatch). Claude and Cursor read disable-model-invocation into userInvocable: false. The Muse provider has no equivalent.
• The newest nightly, v0.1.8-nightly.20261104.4192, has the same turn/start shape.
• Open PR fix(provider-muse): show skills in the composer pickers #20774 sends the first confirmed mention as one structured Muse skill input, which appears to fix this.

Steps to reproduce

1. Put a user skill with disable-model-invocation: true in its frontmatter in ~/.agents/skills/<name>/SKILL.md (e.g. wait-what).
2. Start a thread on the Muse Code provider (model muse-wonder-1.0).
3. Send $wait-what (typed or picked from the $ picker).
4. The model calls read_skill and gets code: disabled-skill. The skill does not run.
5. Control: a skill without the flag (e.g. grilling) loads with status="ok".
6. Control: $wait-what on a Claude thread runs.

Version

T3 server v0.1.7-nightly.20261103.9004138: a local build of upstream Nightly v0.1.7-nightly.20261103.4138 plus local patches (Muse picker discovery and usage limits only; none touches the prompt/turn/start path). The send path is unchanged in upstream v0.1.8-nightly.20261104.4192. (Triage CLI: 0.1.3-nightly.20261023.3592.)

Environment

• Server host: Debian 13 (trixie) x86_64 LXC, T3 running as a systemd user service (t3 serve)
• Client: T3 Code desktop app (Windows 11) and browser, connected to that remote server
• Muse Code 1.4.14 (1.4.14-R7309.1), model muse-wonder-1.0
• Skills in ~/.agents/skills (user scope); project in /work/Design_Experiments

Evidence

Provider event log on the server host, incoming Muse events (trimmed):

2026-11-04T18:55:51Z read_skill {"name":"wait-what"} -> code: disabled-skill, message: skill is disabled: wait-what
2026-11-04T19:51:21Z read_skill {"name":"grill-me"}  -> code: disabled-skill
2026-11-04T19:51:21Z read_skill {"name":"to-spec"}   -> code: disabled-skill
2026-10-24T12:01:19Z read_skill {"name":"grilling"}  -> status="ok" (control: model-invocable skill)

Every failing skill has `disable-model-invocation: true`; every working one does not.

Related issues

• [Bug]: Muse provider doesn't surface Personal/Project skills in composer skill picker #19155: Muse skills are missing from the composer picker. This is the same root area (the Muse provider has no skill model), but a different symptom: discovery, not invocation.
• fix(provider-muse): show skills in the composer pickers #20774 (open PR): structured Muse skill input on turn/start. It looks like the fix for this issue too.
• [Bug]: Cursor provider: /skill and $skill can't invoke skills with disable-model-invocation: true (agent SDK) #15606: the same bug class on the Cursor provider (disable-model-invocation: true skills can't be invoked).
• [Bug]: With several Claude skill chips, only the last is invoked; the rest become plain text, so a disable-model-invocation skill cannot run #20367, [Bug]: Claude skill discovery drops disable-model-invocation, so #7673's /name insertion can never fire — user-invocation-only skills still unreachable on 0.0.38-nightly #9161 (closed): the Claude-side versions of this problem, already fixed there.

Fix applied or workaround

None applied. Workarounds: run user-only skills on a Claude thread, or remove disable-model-invocation: true from the skill (this changes its meaning for every harness).

Filed by

Drafted with t3 triage by Claude Code (Opus 5.5, claude-opus-5-5), reviewed by the reporter.