Are Claude skills and Cursor skills the same thing?

Mostly. Both are Agent Skills: a folder with a SKILL.md file that has name and description in YAML frontmatter and Markdown instructions in the body. The same file works in both tools. They differ in directory paths, optional frontmatter fields, invocation shortcuts, and cloud behavior.

Can I use a Claude Code skill in Cursor without changing it?

Yes, for the vast majority of skills. Cursor reads the .claude/skills directory for compatibility, and any skill that uses only name, description, and a Markdown body loads unchanged. Claude-specific fields like context: fork, hooks, or user-invocable are ignored by Cursor rather than causing an error.

Where do Cursor skills live?

Project skills live in .cursor/skills or .agents/skills inside the repo. Personal skills live in ~/.cursor/skills or ~/.agents/skills. Cursor also scans the Claude and Codex skill directories, so a repo that already ships .claude/skills works in Cursor too.

Where do Claude Code skills live?

Personal skills live in ~/.claude/skills, project skills in .claude/skills, plugin skills inside the plugin's skills folder, and enterprise skills in the managed settings directory. Nested .claude/skills folders inside a monorepo also load once Claude touches a file in that subtree.

Which one should I write skills for first?

Neither. Write to the open Agent Skills spec: name, description, license, and a plain Markdown body under 500 lines. Then add tool-specific frontmatter only when you need a feature one tool offers, such as Claude's allowed-tools or Cursor's paths globs. A spec-clean skill installs into both with one command.

Claude skills vs Cursor skills: what's actually different (2026)

If you only remember one thing from this article, make it this: a Claude skill and a Cursor skill are the same file. Both tools implement the open Agent Skills specification, both read a SKILL.md with name and description in the frontmatter, and both load the Markdown body only when a task matches. A skill written for one loads in the other with no edits in the common case.

So why does “Claude skills vs Cursor skills” get searched so often? Because the two tools diverge in the details that bite you in practice: where the file has to sit, which optional frontmatter fields each one honors, how you trigger a skill by hand, what happens when two skills share a name, and what survives when the agent runs in the cloud instead of your laptop. This article walks through every one of those differences with the exact paths and field names, then closes with a decision guide.

The shared foundation: the Agent Skills spec

Anthropic published Agent Skills as an open standard in December 2025 at agentskills.io, and Cursor, OpenAI Codex, GitHub Copilot, Gemini CLI, and dozens of other agents adopted it. The spec is small on purpose:

Spec element	Rule
Location	A directory containing `SKILL.md`, optionally `scripts/`, `references/`, `assets/`
`name`	Required. 1 to 64 chars, lowercase letters, digits, hyphens. Must match the folder name.
`description`	Required. 1 to 1024 chars. Says what the skill does and when to use it.
`license`	Optional. A license name or a pointer to a bundled license file.
`compatibility`	Optional. Up to 500 chars of environment requirements.
`metadata`	Optional. String-to-string map for anything else.
`allowed-tools`	Optional, experimental. Space-separated pre-approved tools.
Body	Plain Markdown. Recommended under 500 lines and under roughly 5,000 tokens.

Both Claude Code and Cursor implement progressive disclosure the same way: at startup only name and description enter the context (about 100 tokens per skill), the body loads when the skill activates, and files under scripts/ or references/ load only when the body points at them.

Everything below is what each tool adds on top of, or does differently from, that shared core.

Where skills load from

This is the first practical difference, and the one that generates the most “my skill isn’t showing up” questions.

Scope	Claude Code	Cursor
Project	`.claude/skills/<name>/SKILL.md`	`.cursor/skills/<name>/SKILL.md` or `.agents/skills/<name>/SKILL.md`
Personal	`~/.claude/skills/<name>/SKILL.md`	`~/.cursor/skills/<name>/SKILL.md` or `~/.agents/skills/<name>/SKILL.md`
Compatibility scan	None: Claude Code reads only its own directories	Also reads the Claude and Codex directories in the project
Nested (monorepo)	`.claude/skills/` inside a subfolder loads when Claude reads or edits a file there	Skills in nested project folders are discovered recursively and scoped to that folder
Plugins	Plugin `skills/` folder, exposed as `/plugin-name:skill-name`	Not a separate concept; skills are skills
Managed / enterprise	Managed settings directory, for example `/etc/claude-code/.claude/skills/` on Linux	No documented equivalent
Parent directories	Walks up from the start directory to the repo root	Recursive discovery within the project

The compatibility-scan row matters a lot. If your repository already ships .claude/skills/ for Claude Code users, a Cursor user opening the same repo gets those skills automatically. The reverse is not true: Claude Code does not look in .cursor/skills/. If your team is mixed, the vendor-neutral .agents/skills/ path is read by Cursor, Codex, and Copilot, but not by Claude Code, so the practical choice for a mixed repo today is .claude/skills/ (read by Claude Code, Cursor, and Copilot) or a CLI that installs to both.

The SkillMD CLI takes the second route. One command places the file in every agent’s directory it detects on your machine:

npm i -g skillmds
skillmd add anthropic/skill-creator            # every agent detected on this machine
skillmd add anthropic/skill-creator -a cursor  # just Cursor
skillmd add anthropic/skill-creator -a claude-code -g  # Claude Code, personal scope

Per-agent paths for all 60+ supported agents are listed at skillmd.com/agents, and the Claude Code and Cursor guides have the copy-paste versions.

Frontmatter: which fields each tool actually reads

The spec defines six fields. Both tools extend it. Here is the union, with what happens to each field in each tool.

Field	Claude Code	Cursor	Notes
`name`	Read	Read	Cursor requires it to match the folder and be lowercase; Claude derives the slash command from the folder name
`description`	Read	Read	Both use it for automatic triggering
`license`, `compatibility`, `metadata`	Read (passed through)	`metadata` read; others tolerated	Spec fields, safe everywhere
`allowed-tools`	Read. Pre-approves tools for the invoking turn only	Not honored	Claude also substitutes `${CLAUDE_SKILL_DIR}` inside Bash rules here
`disallowed-tools`	Read. Removes tools while the skill is active	Not honored	Claude only
`disable-model-invocation`	Read. Only you can run it via `/name`	Read. Same meaning: manual `/skill-name` only	The one behavioral field both share
`user-invocable: false`	Read. Hidden from the `/` menu, Claude-only	Not honored	Claude only
`paths`	Not honored	Read. Glob patterns that scope the skill to matching files	Cursor only
`argument-hint`	Read. Autocomplete hint for `/name` arguments	Not honored	Claude only
`context: fork`, `agent`, `background`	Read. Runs the skill in a subagent	Not honored	Claude only
`model`	Read. Model override for the turn	Not honored	Claude only
`hooks`	Read. Registers hooks for the session	Not honored	Claude only
`icon`, `color`	Not honored	Read. Badge appearance in Custom Mode	Cursor only

Two things to notice. First, unknown fields are ignored in both tools, so a Claude skill with context: fork still loads in Cursor; it simply runs inline. Second, the claude.ai upload path is stricter than Claude Code: uploads to claude.ai and the Skills API accept only the six spec fields and reject anything else with an “Unexpected key(s)” error. If you publish one skill for both Claude Code and claude.ai, keep the Claude Code extras out of the frontmatter or maintain two builds.

How you invoke a skill by hand

Both tools trigger skills automatically by matching your request to the description. Both also let you force one. The mechanics differ.

Claude Code. Every skill is also a slash command named after its folder. /deploy-staging runs .claude/skills/deploy-staging/SKILL.md. Custom commands have been merged into skills, so a legacy .claude/commands/deploy.md and a .claude/skills/deploy/SKILL.md both produce /deploy, with the skill winning if both exist. You can pass arguments, which the body receives as $ARGUMENTS, and you can stack up to six inline skills in one message. The skill body enters the conversation once and stays there for later turns; the allowed-tools grant, by contrast, clears when you send your next message.

Cursor. Type / in chat to search and invoke a skill for one message. To keep a skill active for the entire session, use Custom Mode: Option+Enter on Mac or Alt+Enter on Windows. The /migrate-to-skills built-in skill (Cursor 2.4 and later) converts your old dynamic “Apply Intelligently” rules and slash commands into skills, adding disable-model-invocation: true to the converted commands so they stay manual.

If you write a skill that has side effects (deploying, committing, sending messages), set disable-model-invocation: true. It is the one control field both tools honor, and it stops either agent from deciding on its own that your code looks ready to ship.

Name collisions and precedence

Teams hit this the moment two people write a deploy skill.

Claude Code has a documented precedence chain:

A personal skill in ~/.claude/skills/ beats a project skill of the same name.
A project skill replaces a bundled skill with the same name (your code-review replaces the built-in /code-review, but the built-in alias /review never runs yours).
A plugin skill is namespaced (/my-plugin:deploy) and coexists with a project deploy.
A skill beats a legacy command of the same name.
A project skill beats a claude.ai-synced skill of the same name.
Nested monorepo skills with a clashing name stay available under a path-prefixed name like /apps/web:deploy.

Cursor scopes nested skills to their containing directory and discovers recursively, but does not publish an equivalent precedence table. In practice: keep names unique across the repo and avoid reusing built-in names, and you will not have to reason about either tool’s tie-break rules.

Cloud, remote, and synced sessions

This is where the two tools diverge most, and where a skill that works perfectly on your laptop silently vanishes.

Cursor. User-level skills in ~/.cursor/skills or ~/.agents/skills are not copied to Cloud Agents, remote SSH sessions, or self-hosted workers. Only project skills committed to the repo (or baked into a worker image) exist in those environments.

Claude Code. Cowork sessions and cloud sessions, including routines, do not read ~/.claude/skills/ on your machine. They load the skills you enabled for your claude.ai account, synced at session start, plus project skills committed to .claude/skills/ in the cloned repo. Locally, setting CLAUDE_CODE_SYNC_SKILLS in a non-interactive run downloads your claude.ai skills into ~/.claude/skills/synced/ (the folder name synced is reserved for this).

The rule that follows for both tools is identical: anything a cloud or remote agent must have belongs in the repository. Personal skill directories are a laptop convenience.

Live reload and iteration speed

Claude Code watches its skill directories and picks up added, edited, or removed SKILL.md files within the current session, no restart needed (a brand-new top-level skills directory does need a restart so the watcher can attach). Cursor’s documentation covers discovery rather than live watching; in practice, re-opening the skill picker after editing is the reliable path. Neither difference affects the published file, but it shapes how fast you can iterate on a description until the skill triggers reliably.

Rules, CLAUDE.md, and what a skill should not be

Both tools have an always-on instruction layer that predates skills, and both push you to move procedural content out of it.

In Claude Code, CLAUDE.md holds facts about the project that should always be in context. The documentation’s own guidance: when a section of CLAUDE.md grows into a procedure rather than a fact, make it a skill, because a skill’s body costs nothing until it is used.
In Cursor, .cursor/rules/*.mdc files with alwaysApply or globs are the always-on layer. Skills are the on-demand layer. The Cursor rules vs Cursor skills article covers the conflict cases in detail.

The heuristic is the same in both: facts and constraints go in the always-on file; procedures and reference material go in a skill.

Side-by-side summary

Dimension	Claude Code	Cursor
File format	Agent Skills spec `SKILL.md`	Agent Skills spec `SKILL.md`
Project dir	`.claude/skills`	`.cursor/skills`, `.agents/skills`, plus Claude and Codex dirs
Personal dir	`~/.claude/skills`	`~/.cursor/skills`, `~/.agents/skills`
Auto-trigger	By `description`	By `description`, optionally narrowed by `paths` globs
Manual trigger	`/name [args]` with `$ARGUMENTS`	`/` picker for one message, Custom Mode for a session
Manual-only flag	`disable-model-invocation: true`	`disable-model-invocation: true`
Agent-only flag	`user-invocable: false`	Not available
Tool permissions	`allowed-tools`, `disallowed-tools`	Not in frontmatter
Run in isolation	`context: fork` with `agent`	Not available
Hooks from a skill	`hooks` field	Not available
Distribution unit	Plugins (`.claude-plugin/plugin.json`)	Skills folders; `/migrate-to-skills` for legacy rules
Cloud behavior	claude.ai-synced skills plus repo skills	Repo skills only; personal skills not copied
Live reload	Yes, within a session	Re-open picker after edits

Decision guide

You write skills for yourself, on one machine, in one tool. Use that tool’s personal directory and whatever extra fields it offers. If you are in Claude Code, allowed-tools and context: fork are worth learning; if you are in Cursor, paths globs keep a framework-specific skill from firing on unrelated files.

You maintain a repository other people clone. Commit skills to .claude/skills/. Claude Code, Cursor, and GitHub Copilot all read that path, and Codex users can install the same skills with one CLI command. Use only spec fields plus disable-model-invocation where needed. Run a linter before you commit; skillmd lint checks the frontmatter constraints and warns on missing licenses and thin descriptions.

You publish skills for strangers to install. Write to the spec, nothing else. Put a license in. Keep the body under 500 lines and move reference material into references/. Publish to a registry so people can find it: SkillMD lists 25,000+ skills, every public one passes a safety review before it is visible, and each listing shows which agents the author tested against. Installation is one command in either tool, or one prompt through the hosted MCP server in Claude Code:

claude mcp add skillmds -- npx -y skillmds

You are choosing between the two editors because of skills. Do not. Skill support is not a differentiator between Claude Code and Cursor anymore; the format is shared and the registry ecosystem is shared. Choose the editor on everything else, and bring your skills with you.