[Feature]: Cursor skill picker, invocation, and description-based matching

[boonguan]

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

apps/web

Problem or use case

When the active provider is Cursor, T3 Code does not surface or invoke Cursor Agent Skills the way Cursor itself (and T3's Claude/Codex providers) do.

Concretely, in a Cursor thread:

1. Typing / only shows T3 built-ins such as /model. None of my Cursor skills appear.
2. Typing $ does not list Cursor skills either.
3. There is no way to explicitly invoke a skill ($skill-name / /skill-name) or to have the composer match a query against skill description fields the way Cursor IDE does.

The skills exist on disk and work in Cursor. T3's Cursor provider cache just does not expose them.

Fresh evidence on T3 Code 0.0.33 / cursor-agent 2026.08.11-e8db854 (2026-08-14):

Provider cache	skills	slashCommands
~/.t3/caches/cursor.json	0	0
~/.t3/caches/claudeAgent.json	26	92

Cursor-side skills that should be visible, for example:

• ~/.cursor/skills/ (user): cursor-doctor, go-programming, …
• ~/.agents/skills/ (Agent Skills standard): lark-doc, longbridge, investment-report-evaluation, …
• project .cursor/skills/ when present

Claude in the same T3 install already lists those skills in $ / /. Cursor does not.

This is related to, but not the same as, #2736. That bug tracks empty Cursor/OpenCode discovery. This request is the product behavior on top: picker matching, explicit invocation, and description-based auto-apply, at Cursor parity.

Proposed solution

Give Cursor the same skill UX T3 already has for Claude/Codex, plus Cursor's own matching rules.

1. Discover user/project Cursor skills from the usual roots, scoped to the thread/project cwd:
   • ~/.cursor/skills, <project>/.cursor/skills
   • ~/.agents/skills, <project>/.agents/skills
   • Cursor built-in / plugin skills if cursor-agent already reports them over ACP
2. Match in the composer
   • $ picker lists skills with name + description, fuzzy-matched (same ranking as Claude/Codex).
   • / should not swallow skill names into T3 built-ins only. If Cursor exposes a skill as a slash command, show it; otherwise keep skills on $ and document that.
3. Explicit invocation — selecting a skill inserts $skill-name (or the Cursor-native token) and actually loads that SKILL.md for the turn, including skills with disable-model-invocation: true that only run when named.
4. Description-based matching — keep Cursor's auto-apply: the agent sees each skill's YAML description (WHAT + WHEN) and loads the matching SKILL.md from a natural-language prompt, without the user having to type $. T3 should not drop ACP available_commands_update on the floor.

A comment on #2736 already notes that cursor-agent acp sends available_commands_update on session/new with the full skill list, and T3 currently decodes it then ignores it (CursorProvider.ts never passes slashCommands/skills into buildServerProvider, so they default to []). Wiring that update through is likely enough for discovery; invocation + matching still need the composer and turn path.

Why this matters

Skills are how people encode repeatable workflows (review, deploy, domain tools). Claude/Codex users already get $ chips and matching inside T3. Cursor users have to paste SKILL.md by hand or leave T3 for the Cursor IDE. That makes Cursor-in-T3 a second-class harness for anyone with a real skill library.

Smallest useful scope

• Populate Cursor skills (and slash commands if ACP reports them) from ACP available_commands_update and/or a cwd-scoped filesystem scan.
• Show them in the $ picker with name+description fuzzy match.
• Selecting one invokes the skill for that turn (body actually loaded, not just a chip).

Auto-apply from description can follow once the catalog is in the agent context.

Alternatives considered

• Continue using Cursor IDE / CLI for skill-heavy work — defeats the point of T3 as a Cursor harness.
• Paste SKILL.md into the prompt — works, does not scale.
• Wait only on [Bug]: Cursor/OpenCode skill discovery returns zero skills despite skills existing on disk (Claude/Codex discover them fine) #2736 / feat(cursor): cursor skills discovery #5168 — those cover discovery into the $ picker; they do not specify invocation of disable-model-invocation skills or description-based matching.

Risks or tradeoffs

• Cursor ACP handleSlashCommand reportedly checks the commands map, not skills, so /foo may not fire for disable-model-invocation: true skills. That part may need a Cursor-side fix; T3 can still invoke via $ / prompt injection.
• Skill inventory is cwd-scoped (project vs user vs worktree). Snapshot-at-server-start is the wrong model; feat(cursor): cursor skills discovery #5168's per-thread inventory is the right shape.
• Do not ship skill bodies in the provider snapshot; metadata (name, description, path, scope) is enough for the picker.

Examples or references

• [Bug]: Cursor/OpenCode skill discovery returns zero skills despite skills existing on disk (Claude/Codex discover them fine) #2736 — Cursor/OpenCode skill discovery returns zero skills
• feat(cursor): cursor skills discovery #5168 — feature(cursor): cursor skills discovery (open PR, $ picker)
• [Feature]: Discover repo-local .agents/skills (Agent Skills standard) provider-agnostically, not per provider #5492 — provider-agnostic .agents/skills discovery
• Cursor skill format: SKILL.md with YAML name / description; optional disable-model-invocation: true
• Cursor skill roots: ~/.cursor/skills, .cursor/skills, ~/.agents/skills, .agents/skills

[juliusmarminge]

Closing: current main already covers this as of 15fea6c5f4. If you still see it on a build that includes that commit, reply and we'll reopen.