[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

[RostyslavDzhohola]

Before submitting

Searched: #8295, #7673, #6095, #7671, #7795, #8757, #7757, #5622. #8295 covers the composer
symptom and is closed as completed by #7673. This report is the reason that fix does not take
effect: the flag it keys on is never captured by skill discovery. Filing separately because the
defect is in discovery/metadata, not ChatComposer.tsx.

Area

Skill discovery (Claude provider)

Environment

• T3 Code 0.0.38-nightly.20260901.1250 (desktop, com.t3tools.t3code)
• macOS 26.6.2, arm64, Darwin 25.6.0
• Claude Code CLI 2.1.258
• Provider: Claude (Opus 5)
• Skill: ask-matt from mattpocock-skills@mattpocock 1.2.3, resolved at
  ~/.claude/skills/ask-matt/SKILL.md

---
name: ask-matt
description: Ask which skill or flow fits your situation. A router over the skills in this repo.
disable-model-invocation: true
---

Steps to reproduce

1. Install a Claude skill whose frontmatter sets disable-model-invocation: true.
2. In an empty composer, invoke it any of these ways:
   • pick it from the / menu,
   • pick it from the $ menu,
   • type $ask-matt literally,
   • type /ask-matt literally.
3. Send.

Expected behavior

At least one path yields a turn whose user text contains a literal /ask-matt at message start,
which the CLI accepts as explicit user invocation and expands into an injected SKILL.md.

Actual behavior

No path does. The agent's only remaining route is the Skill tool, which correctly refuses:

Skill ask-matt cannot be used with Skill tool due to disable-model-invocation.
Ask the user to run /ask-matt themselves — it cannot be invoked via the Skill tool.
Do not replicate this skill's workflow by other means — it is reserved for explicit user invocation.

All 22 user-invocation-only skills in the Matt Pocock set are unreachable in T3 Code as a result.

Control — this is client-side, not a CLI or skill problem. Same machine, same skill, plain CLI:

$ cd /tmp && claude -p "/ask-matt DIAGNOSTIC ONLY — do not act. Reply with the first sentence of
  the skill instructions you received, or exactly 'NO SKILL LOADED'." --max-turns 2
SKILL LOADED — `/ask-matt`, base directory `/Users/…/.claude/skills/ask-matt`.
> You don't remember every skill, so ask.

Root cause

~/.t3/caches/claudeAgent.json — every discovered Claude skill is stored with exactly five keys.
disable-model-invocation is parsed out of the frontmatter and discarded:

== claudeAgent.json: 79 skills, entry keys = ['description', 'enabled', 'name', 'path', 'scope']
   any invocation-related key? []

Per @Brechard's 2026-08-28 comment on #8295, the shipped rule is that picking a skill inserts
$name from either menu, and /name is used only for "a skill marked disable-model-invocation
picked at the very start of a message."

T3 Code has no such mark. The predicate reads a field that discovery never writes, so it is
always false, every pick falls through to $name, and #8295's symptom survives its own fix. This
matches @4dlt's unanswered "still happening on 0.0.37" and reproduces unchanged on 0.0.38-nightly.

The / route itself is wired up correctly — these skills are registered as slash commands:

slashCommands: 102; flagged present:
  ['ask-matt', 'grill-with-docs', 'implement', 'to-spec', 'to-tickets', 'wayfinder']

So the destination exists; nothing routes to it.

Suggested fix

Capture disable-model-invocation in the Claude skill discovery result and persist it on the
cached entry, so the #7673 predicate has something to read. Worth a regression test asserting a
flagged skill's cache entry carries the flag — the composer fix is untestable end-to-end without it.

Possibly related

All 79 Claude skills report scope: "project" in the same cache despite resolving under
~/.claude/skills. Codex's cache reports system/user correctly. That is #8757; noting it only
because it is visible in the same records.

Note

I could not inspect the composer source in the installed build (the web UI is not in app.asar),
so the predicate behaviour above is taken from the #8295 thread rather than read from this
binary. The cache evidence and the control run are from this machine directly.