Summary
Skills appear and work in the Cursor desktop application but are not
displayed (or are missing / inconsistent) in Cursor CLI, so CLI sessions
cannot rely on the same Skills as the desktop agent.
Expected behavior
CLI should expose the same Skills as the desktop app (or the docs should
clearly state the limitation). Skills configured for the desktop should be
listed and usable in CLI sessions where applicable.
Actual behavior
Skills are not shown in CLI (or behavior diverges from desktop).
Steps to Reproduce
Steps to reproduce
Confirm Skills are visible and working in the desktop app.
On the same machine, open a terminal and use Cursor CLI in a flow where
Skills would apply.
Check where Skills are listed or referenced.
Observe that CLI does not show Skills or differs from desktop.
There’s no file watcher in the CLI, so skills added during a session won’t show up until you restart
Some cases are already fixed in newer CLI versions (loading ~/.cursor/skills, auto-trigger via natural language). You’re on 2026.04.17, so those fixes should apply.
To figure out which case you’re hitting, can you share:
Where the skills that show up in desktop but not in CLI are located project .cursor/skills, user ~/.cursor/skills, plugin, nested
~/.cursor/skills/writing-skills/ is the standard location and the CLI should pick it up. To figure out why it’s not working, please check:
Is there a SKILL.md file inside writing-skills/?
Does it include YAML frontmatter with name and description fields?
Please share the output of ls -la ~/.cursor/skills/writing-skills/ and the first lines of SKILL.md if it exists.
The /skills slash command doesn’t show up in autocomplete, you only see /show-thinking. Please try:
Type /skills fully and press Enter, does it print anything?
Run agent --help and share the output so we can confirm which commands are registered.
Workaround for item 1 for now: you can copy or symlink the skill folders you need from ~/.agents/skills/... into ~/.cursor/skills/. That’s the standard location the CLI uses.
I have tested the symlink solution but it would be great to have native support here at some pt. I think symlinks can be brittle and may become stale over time if a plugin directory shifts due to versioning etc.
Hey @droth_nyt, totally agree. A symlink is a temporary workaround, and it can really break after plugin updates. Native support for plugin skills in the CLI is on our radar, it’s part of the work to bring CLI and desktop to parity. I can’t share an ETA yet, but as soon as I have an update I’ll post it either here or in the main thread about this gap: Cursor-agent CLI does not register skills from plugins (IDE does — parity gap)
