[Feature]: Auto-discover Claude skills #1480

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

multiple

Problem or use case

I've seen some confusion in #1283 after the related PR was merged, which is valid from a UX standpoint: ideally, when I write /, I should see the slash commands my Claude Code has access to.
However, that's not the case today. The point of that issue and PR was to give the SDK access to the user / project configurations, thus allowing Claude Code to internally discover those resources so it can reuse them, which is unrelated to T3 Code's UI.

Which is why I'm making a proper feature request here !

The point of the feature would be to allow T3 Code to discover those commands automatically.

However, things are not that simple today:

• The command selector currently only handles hardcoded commands (/model, /plan /default)
• Claude's SDK provides a slash_commands in its session/init event
• But, since we can't naturally get the information out before engaging a session, the first message of a thread cannot have the suggestions.
• Also, they only provide the skill names, so we don't have access to descriptions / metadata

Proposed solution

Discovery:

• Walk through the main configuration scopes (user, project, etc...) and for each skill, extract:
  • name
  • description (if applicable)
  • user-invocable (determines whether it can be called as a command or not)
  • scope (where we found it)
• Build an array of slashCommands that will contain (for commands where user-invocable !== false:
  • name: name of the command
  • description (optional): small description if the command has one
  • scope: Which configuration it comes from. If none, it is certainly a built-in

After the discovery part is solved, the rest is fairly straightforward:

• Allow the command menu to be more extensible to receive commands from different "providers" (I believe the three commands are hardcoded today?)
• Pass the discovery results down to the picker (I was thinking of a fs watcher with cache, like we do with settings, and then pass it down through the websocket)
• Show it to the user depending on which model is selected (so that we show Claude commands only when a Claude model is selected)

Unlike T3 Code's special commands (/model, /plan, /default), no hooks should be needed to catch the commands: this is handled by the Claude Code.

Why this matters

People don't want to know all their slash commands by heart, it's just good UX to give them a list of what they can do :)

Smallest useful scope

Would be very clunky, but we could grab the information from the session/init event so that we don't bother with the filesystem, which would only leave us with the command, no description or scope.

Alternatives considered

There are a few mitigations possible for the discovery part, but somewhat clunky:

• Rely solely on the session/init event from Claude SDK
  • => Claude only provides the name of the skill, nothing else
  • => Can only be done after engaging a session
• Make it a setting where the user can specify their skills and commands
  • => Defeats a bit of the purpose given that they could just write the slash command directly in their prompt and Claude Code would recognize it, this would not be great UX anyway
• A small, invisible session to parse the session/init event or Claude
  • => Claude only, and using tokens behind the user's back is a no-go :)

For passing down the information and when it triggers:

• Instead of a watcher, we could just do it on demand when opening the commander, but this adds overhead and might be overkill.
• Storing the information, should not be needed. Becomes a nightmare to manage down the road.

Risks or tradeoffs

Not everything here will end up being an actual risk, just getting everything out of my head

• Overhead of having to search the filesystem and parse files
• We might someday parse a malicious file
• We might miss some skills if we're not thorough (in monorepos for example)
• User has some skills that aren't in the places we check (legacy places like .claude/commands/) ?

Examples or references

Example UI (didn't grab the description here):

Contribution

• I would be open to helping implement this.