Do Agent Skills Work in Codex, Cursor and Other Agents?
The SKILL.md format is open, so the same folder usually runs in more than one agent. Here is what transfers, what does not, and how to check before you install.
Fastest way
Ask your AI to do it
Paste this into the AI agent you already use:
Check whether an Agent Skill will work in my AI agent. Ask which agent I use and for the Skill folder or link. Then check its install directory, required tools, and agent-specific dependencies, and tell me exactly what will work, what may not, and what I should change.
Mostly, yes. A skill is a folder of plain files and the format is open, so any agent that reads SKILL.md can run the same skill. What differs between agents is where the folder goes, how the agent decides to use it, and whether the tools a particular skill depends on are available.
The short version
- The instructions themselves are portable. They are just text.
- The install directory differs per agent. This is the main thing that breaks.
- Matching behaviour differs — the same skill may fire readily in one agent and need a nudge in another.
- Skills that depend on a specific model or a host-only capability do not transfer.
- One folder in
~/.agents/skillsserves several agents at once.
Why skills travel between agents
There is no runtime to be locked into. A skill is a directory containing a markdown file with two frontmatter fields, plus whatever reference documents and scripts it needs. Nothing is compiled and nothing registers against a host API.
So "does this Claude Skill work in Cursor" is mostly the wrong question. The better one is: does Cursor look in the folder where I put it, and does this particular skill depend on anything Cursor cannot do?
What transfers and what does not
| Layer | Portable? | Notes |
|---|---|---|
Instructions in SKILL.md | Yes | Plain text. Every agent reads it the same way |
| Reference docs, templates, examples | Yes | Same |
| Install directory | No | Different per agent — see the table below |
| When the agent decides to use it | Partly | Agents differ in how they match a request to a description |
| Required models or host-only capabilities | No | A skill built around one model's image generation needs that model |
Scripts in scripts/ | Partly | Depends on whether the agent will run local scripts at all |
The pattern: content travels, plumbing does not.
Where each agent keeps its skills
| Agent | Skills directory |
|---|---|
| Claude Code | ~/.claude/skills |
| Codex | ~/.agents/skills |
| Cursor | ~/.agents/skills |
| Gemini CLI | ~/.agents/skills |
| OpenCode | ~/.agents/skills |
| Kimi Code CLI | ~/.agents/skills |
| Antigravity | ~/.gemini/config/skills |
~/.agents/skills is a shared convention. Put a skill there once and several agents pick it up — that is the practical answer to "can I use one skill in two tools."
Claude Code is the notable exception with its own directory. If you work across both, either install twice or keep one canonical copy and symlink.
If your agent is not listed, check its documentation rather than guessing. A skill in the wrong folder fails silently.
Why the same skill behaves differently in two agents
Assume it is not broken. Work through these in order:
- Wrong folder. Most common by far. Verify against the table.
- Old session. Agents scan at session start. Open a new one.
- The description did not match. Agents differ in how eagerly they match a request to a skill's
descriptionline. Run the skill's own demo prompt verbatim — if it fires then, the skill is fine and your phrasing was the variable. - Missing dependency. If the skill calls an outside model or service, check its dependency notes.
- Genuine host limitation. Rare, but real for skills built around one host's exclusive capability.
How to check before you install
Every Skill on Skillry shows two rows that answer this directly, and they are different claims:
Runs in — declared compatibility. The skill format is open, so a Skill is marked compatible with every mainstream host unless it genuinely depends on one host's exclusive capability. This is a statement about the skill's design.
Last tested — what we actually ran, and when. A date and a list of agents. This is a statement about our testing.
We keep them separate deliberately. Marking fewer hosts as "compatible" to imply caution would be dishonest, and so would letting broad compatibility imply we tested everywhere. If Last tested is empty, we do not show the row at all — we do not write "untested" and we do not quietly leave the impression that we checked.
When a Skill's Last tested list does not include your agent, the honest read is: it should work, and nobody has confirmed it in your setup yet.
Questions people ask
Can I use a Claude Skill in Cursor?
Usually. The instruction files are identical; the install directory differs — ~/.claude/skills for Claude Code, ~/.agents/skills for Cursor. Skills that depend on a Claude-only capability will not transfer.
Does Codex read SKILL.md?
Codex reads skills from ~/.agents/skills, the shared directory several agents use. That is where our CLI installs by default.
Will one folder work in two agents at once?
Yes, if both read the same directory. Several agents share ~/.agents/skills. For Claude Code you need a second copy or a symlink, since it reads its own path. Keep one canonical source so versions do not drift.
Why does the same skill give better output in one agent? Output quality depends on the underlying model as much as the instructions. The skill fixes the method; the model still does the work.
How do I know which agents a skill was actually tested in?
Look for the Last tested row on the Skill page. Runs in tells you what it is designed to support; Last tested tells you what we ran.
What if my agent is not on the list?
Find its skills directory in its own documentation, then install with --target <directory> rather than --agent. Never guess a path.
Next
Browse the Skill directory — every Skill page lists the agents it runs in, and shows real output from the Skill itself.