You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Cursor provider: /skill and $skill can't invoke skills with disable-model-invocation: true (agent SDK) #15606
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
Put a skill in ~/.agents/skills/ whose frontmatter sets disable-model-invocation: true (for example grill-me).
Open a Cursor thread in T3 Code.
Send /grill-me <request> or $grill-me <request>.
Expected behavior
The skill's SKILL.md is loaded into the turn and the agent follows it, the same as typing /grill-me in Cursor's own composer.
Actual behavior
The agent receives /grill-me as plain text and can't find the skill.
The skill isn't missing from discovery. The model-facing skill list shows other skills from the same ~/.agents/skills/ folder (for example grilling and code-review). All 10 skills there with disable-model-invocation: true are absent: grill-me, implement, to-spec, handoff, show-me, retro, ask-matt, improve-codebase-architecture, grill-with-docs and setup-matt-pocock-skills.
For skills with disable-model-invocation: true, Cursor hides them from the model and only loads them when its own composer handles the slash command. The agent SDK has no equivalent expansion: the prompt reaches the model as text, and the skill was never listed, so the model has no way to look it up. The Claude fix (#7673 / #9161) hands /name to the CLI to expand. Cursor's SDK has nothing to hand it to, so T3 would need to expand it itself. On send, it would resolve a leading /name or $name against the discovered Cursor skills, including user-invocation-only ones, and add that skill's SKILL.md to the prompt.
Related: #6581 (Cursor skill picker and invocation), #9161 and #8295 (the same problem on the Claude provider), #13457 (the same problem on the Grok provider).
Impact
Major degradation or frequent failure
Version or commit
0.0.46-nightly.20261004.2648
Environment
macOS 27.0.1 (arm64), T3 Code desktop nightly, Cursor provider via the Cursor agent SDK with orchestrator v2
Workaround
Reference the file directly in the prompt (follow ~/.agents/skills/grill-me/SKILL.md), or remove disable-model-invocation from the skill.
Thanks for the detailed report, @cvpcasada. The frontmatter example and the side-by-side with grilling made this easy to trace.
What I found
I reproduced this from the code on current main. A Cursor skill with disable-model-invocation: true gets discovered and offered in the composer, but it's sent as plain prompt text, so the Agent SDK never attaches its SKILL.md.
parseSkillFrontmatter in CursorSkills.ts records the flag as userInvocationOnly and still returns the skill. The composer keeps it because isProviderSkillUserInvocable only filters out userInvocable: false.
On send, CursorAdapterV2.resolveUserMessage uses that same skill set, and rewriteCursorSkillMentions turns $grill-me into /grill-me. A typed /grill-me isn't a $ mention, so it's passed through unchanged. Either way, agent.send only receives a string. Its options are model, mode, MCP servers, and callbacks, with no skill field.
Cursor's docs say a disable-model-invocation skill is only included when Agent chat invokes /skill-name itself. The model-facing catalog comes from settingSources, which is why grilling shows up there and grill-me doesn't. Rewriting the token doesn't do the composer's attach step, so the model has neither a catalog entry nor the skill body.
Related history: this isn't #6581, which was the empty Cursor skill picker (filesystem discovery has since landed). It's the same gap as #9161 and #8295 on Claude and the open #13457 on Grok, except Cursor already does the $ to / rewrite and that isn't enough here. #8336 tried inlining the skill file and was closed in favor of #9128, so the harness itself runs the skill (with allowed-tools, forks, hooks, and model overrides). That suggests inlining SKILL.md into the prompt isn't the direction either.
Workaround for now: point the prompt at the skill file directly, or remove disable-model-invocation so Cursor lists the skill for the model again.
Likely fix area
CursorAdapterV2.resolveUserMessage and rewriteCursorSkillMentions, if the Cursor SDK exposes (or gains) a way to attach a user-invoked skill on send.
CursorSkills.ts and isProviderSkillUserInvocable, if the better option is to hide or mark user-invocation-only skills in the Cursor composer until invocation is supported.
I can reproduce this with the bro skill (~/.agents/skills/bro, disable-model-invocation: true).
The composer lists it and the turn is sent as /bro. In a Cursor thread the model says no such skill exists. The same /bro prompt works in the agent CLI. The skill is installed, and the CLI loads it. The Agent SDK session T3 opens does not.
This is painful for using Cursor inside T3. It sits next to #16430: the picker and the running agent still disagree about which Cursor skills are actually available.
Activity
juliusmarminge commentedon Oct 4, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the detailed report, @cvpcasada. The frontmatter example and the side-by-side with
grillingmade this easy to trace.What I found
I reproduced this from the code on current
main. A Cursor skill withdisable-model-invocation: truegets discovered and offered in the composer, but it's sent as plain prompt text, so the Agent SDK never attaches itsSKILL.md.parseSkillFrontmatterinCursorSkills.tsrecords the flag asuserInvocationOnlyand still returns the skill. The composer keeps it becauseisProviderSkillUserInvocableonly filters outuserInvocable: false.CursorAdapterV2.resolveUserMessageuses that same skill set, andrewriteCursorSkillMentionsturns$grill-meinto/grill-me. A typed/grill-meisn't a$mention, so it's passed through unchanged. Either way,agent.sendonly receives a string. Its options are model, mode, MCP servers, and callbacks, with no skill field.disable-model-invocationskill is only included when Agent chat invokes/skill-nameitself. The model-facing catalog comes fromsettingSources, which is whygrillingshows up there andgrill-medoesn't. Rewriting the token doesn't do the composer's attach step, so the model has neither a catalog entry nor the skill body.Related history: this isn't #6581, which was the empty Cursor skill picker (filesystem discovery has since landed). It's the same gap as #9161 and #8295 on Claude and the open #13457 on Grok, except Cursor already does the
$to/rewrite and that isn't enough here. #8336 tried inlining the skill file and was closed in favor of #9128, so the harness itself runs the skill (withallowed-tools, forks, hooks, and model overrides). That suggests inliningSKILL.mdinto the prompt isn't the direction either.Workaround for now: point the prompt at the skill file directly, or remove
disable-model-invocationso Cursor lists the skill for the model again.Likely fix area
CursorAdapterV2.resolveUserMessageandrewriteCursorSkillMentions, if the Cursor SDK exposes (or gains) a way to attach a user-invoked skill on send.CursorSkills.tsandisProviderSkillUserInvocable, if the better option is to hide or mark user-invocation-only skills in the Cursor composer until invocation is supported.A maintainer will decide on the fix direction.
Melv1C commentedon Oct 8, 2026
I can reproduce this with the
broskill (~/.agents/skills/bro,disable-model-invocation: true).The composer lists it and the turn is sent as
/bro. In a Cursor thread the model says no such skill exists. The same/broprompt works in theagentCLI. The skill is installed, and the CLI loads it. The Agent SDK session T3 opens does not.This is painful for using Cursor inside T3. It sits next to #16430: the picker and the running agent still disagree about which Cursor skills are actually available.
Is there a timeline for tackling this?