Cursor reads the exact same SKILL.md file that Claude Code reads. It is the same folder, with no Cursor-flavored variant and no conversion step in between. Drop it into .cursor/skills/, restart, and the cursor skills you wrote for Claude last month show up in Cursor's Agent today.
That is the whole story, and most of this article is just proving it and showing you the paths.
Cursor is listed on agentskills.io, the open Agent Skills standard's client directory, alongside Claude Code, Codex, Gemini CLI, Goose, Amp, and roughly forty other agents. The official Cursor skills docs open by calling Agent Skills "an open standard" and link straight back to agentskills.io. The portability isn't a hack or a community workaround. It's the design.
What a skill actually is
A skill is a folder with one required file in it: SKILL.md. That file carries a small block of YAML frontmatter at the top, then Markdown instructions in the body. Two fields are mandatory, name and description, and everything else is optional.
my-skill/
├── SKILL.md # required: metadata + instructions
├── scripts/ # optional: code the agent can run
├── references/ # optional: docs it loads on demand
└── assets/ # optional: templates, files
The name is a lowercase-hyphen identifier and, per Cursor's docs, has to match the parent folder name. The description is the load-bearing field, because it tells the agent what the skill does and when to fire it. Cursor's own documentation is blunt about this: the description is "used by the agent to determine relevance." Write it badly and the skill never triggers. Write it well and it fires exactly when you want it to.
The body is where the work lives. It might be a checklist, a multi-step procedure, your team's deploy ritual, the way you want commit messages formatted, or the seventeen things that always go wrong with your staging database. Cursor only pulls that body into context when the skill activates, so a 300-line skill costs roughly its description's length while it sits idle. The agentskills.io spec calls this progressive disclosure: discovery loads the name and description, activation loads the full body, and execution runs whatever it needs.
This is the same mechanism Claude Code uses, because it is the same file. That is the point worth sitting with before we get to the paths.
Where Cursor looks for skills
Cursor checks four directories, plus a couple of legacy ones it keeps around for compatibility. Here is the verified list from the Cursor docs.
Project-level, committed to your repo and shared with everyone who clones it:
.cursor/skills/.agents/skills/
User-level, global to your machine and available in every project:
~/.cursor/skills/~/.agents/skills/
And here is the part that makes the "same skill" claim concrete. Cursor also reads .claude/skills/ and .codex/skills/ for backward compatibility, so if you already have a .claude/skills/ folder full of skills you wrote for Claude Code, Cursor finds them with zero changes. You don't copy anything, and you don't rename anything. Cursor walks those directories, finds every SKILL.md, and loads it.
Skills can sit in nested subfolders too. Cursor recursively scans for SKILL.md files, so a monorepo can scope a skill to one package by putting it under that package's directory. The paths frontmatter field narrows a skill to matching files with glob patterns, which is how you keep a deploy-web skill from surfacing while someone works in the iOS app.
One honest caveat. I haven't personally regression-tested every legacy path on every Cursor build, and the directory list does shift as the format matures. If a skill doesn't appear, the official docs are the source of truth for your version, not this post. The two paths I'd bet a deploy on, though, are .cursor/skills/ for project work and ~/.cursor/skills/ for the stuff you want everywhere.
Adding a skill, three ways
The manual way takes about ten seconds. Make the folder, drop the SKILL.md in, and restart Cursor so it rescans. A skill at .cursor/skills/code-reviewer/SKILL.md shows up as code-reviewer in Agent. If you downloaded a skill as a zip from a catalog, unzip it into .cursor/skills/ and you are done.
The second way is gh skill. GitHub added skill management to its CLI in version 2.90.0 (changelog, April 16, 2026), and Cursor is one of the named targets, along with Copilot, Claude Code, Codex, and Gemini CLI. The command installs a skill straight from any GitHub repo into the right directory for the agent you name:
gh skill install OWNER/REPO SKILL --agent cursor
You can pin to a release or a specific version, which matters more than it sounds. A skill is a set of instructions an agent will follow, so treating it like a dependency you version and review is the correct instinct:
gh skill install OWNER/REPO SKILL --agent cursor --pin v1.2.0
The third way is inside Cursor itself. Settings has a Rules section that can import a skill from a GitHub remote, and there is a built-in /migrate-to-skills command that converts your existing Cursor rules and slash commands into proper skills. If you have been hand-rolling .cursorrules for two years, that command is worth running once just to see what it produces.
Invoking a skill once it is installed
There are two ways, and you will use both.
Automatic is the default, and it's the better one. Cursor shows the Agent every installed skill's name and description, then lets the Agent decide when one is relevant to what you asked. You say "clean up this PR," and if your code-reviewer skill's description mentions PR review, it fires on its own, with no command and no ceremony. This is the behavior worth optimizing your descriptions for.
Manual is the escape hatch. Type / in Agent chat, search the skill name, and run it. If you set disable-model-invocation: true in the frontmatter, the skill only runs this way, which is what you want for anything destructive or anything you only mean to trigger deliberately. A skill that force-pushes should never fire because the model guessed it was relevant.
Writing a skill Cursor will actually use
The description is the entire game. Cursor's Agent never reads your instructions until the description convinces it the skill is relevant, so a vague description leaves you with a skill that just sits there inert. Compare these two.
Weak: "Helps with database stuff."
Strong: "Run the staging database reset and seed procedure. Use when the user asks to reset staging, reseed test data, or when staging migrations have drifted from main."
The second one names the triggers. It tells the Agent the exact phrases and situations that should wake the skill, and that is the difference between a skill that earns its place and one you forget you installed.
Keep the body procedural and specific, because agents follow concrete steps far better than they follow vibes. "Run npm run db:reset, then npm run db:seed -- --env=staging, then confirm row counts against the fixtures in references/expected-counts.md" beats "reset and seed the database appropriately." Put long reference material in references/ and point to it from the body with a relative path, so the heavy content loads only when the skill is mid-task instead of bloating every prompt.
Scope with paths when a skill belongs to one part of the repo. A skill that knows your API conventions has no business surfacing while someone edits CSS, and a paths glob keeps it quiet until the agent touches the right files.
The portability payoff
Here is what the shared format buys you, stated plainly. Write a skill once and it runs in Cursor, Claude Code, Codex, and Gemini CLI without a single edit, because all four read the same SKILL.md against the same agentskills.io spec. Your .cursor/skills/api-conventions/ and a teammate's .claude/skills/api-conventions/ can be byte-for-byte the same folder. The standard came out of Anthropic and was released openly, and adoption since has been wide enough that "which agent do you use" stopped being a reason to maintain separate instruction sets. (For the full list of what reads the format, see which tools support SKILL.md.)
That changes how a team should think about skills. You aren't writing Cursor skills and Claude skills and Codex skills as three separate things. You are writing skills, committing them once, and letting every coding agent on the team pick them up from the same directory. A new hire on Cursor and a senior on Claude Code get identical behavior because they load identical files.
The friction that remains is authoring. Writing a good SKILL.md means knowing the frontmatter rules, writing a description that triggers reliably, and structuring the body so an agent follows it. That is real work, and it is exactly the part a non-coder gets stuck on. Knack runs a 20-minute interview and produces a valid SKILL.md folder from it, so a domain expert who has never touched YAML can ship a skill their whole team uses. Because the output is the open standard, the skill Knack writes drops straight into .cursor/skills/ and runs in Cursor exactly as it runs in Claude Code.
So does Cursor support skills? Yes, the same ones every other agent does. Make the folder, write a description that fires, and stop maintaining four copies of the same instructions.
If you want to test the portability claim yourself in two minutes, take any SKILL.md you already have, drop it in .cursor/skills/, restart Cursor, and watch it appear in /. If you don't have one yet, Knack will interview one out of you.