Do Agent Skills work outside Claude Code?

The question comes up as soon as someone finds a skill they want and is not using the tool it was written for. It has a satisfying answer: mostly yes, with an asterisk that is about plumbing rather than substance.

The format is deliberately boring

A skill is a directory containing a SKILL.md file. That file is Markdown with a small YAML block naming the skill and describing when it applies.

migration-conventions/
└── SKILL.md

There is no binary, no manifest schema, no registry, no API version. Nothing in it is proprietary or even particularly clever. That is precisely why it travels: any agent that decides to read a folder of Markdown can support the format, and several do. Claude Code popularised the convention; it does not own it.

So when people ask whether skills are “locked in”, the format is not the lock. The discovery mechanism is.

What actually differs between tools

Every coding agent has arrived at some version of the same idea — persistent project-specific instructions the model reads without you pasting them. They differ in three places:

Where it looks. One tool reads ~/.claude/skills/ and .claude/skills/. Another reads a rules directory. Another reads a single instructions file at the repository root. This is the main friction, and it is a cp command.

How it decides to load. The SKILL.md model is on-demand: the agent holds each skill’s name and description, matches your request against them, and pulls in the body only when it looks relevant. Some tools instead load their instruction file always. That difference matters more than it sounds — a description tuned to be a precise trigger is doing nothing useful in a tool that loads everything unconditionally, and twenty always-loaded skills is a context budget problem that twenty on-demand skills is not.

What extras it supports. Slash commands, hooks, subagents, plugin manifests, MCP server configuration. These are genuinely tool-specific. A skill that is purely instructions is portable; a plugin bundling hooks and an MCP server is not.

What transfers and what does not

Part of a skill	Portable?
Conventions, rules, decisions in the body	Yes — this is the substance
Code examples and anti-patterns	Yes
name / description frontmatter	Usually, as metadata; the matching behaviour varies
References to bundled files (reference.md)	Usually, if you copy the whole folder
Bundled scripts	Yes, if the agent can run commands
Slash-command definitions	No
Hook configuration	No
MCP server wiring	No — separate mechanism, see skills vs MCP vs plugins
Plugin manifests / marketplace metadata	No

The pattern: judgement is portable, plumbing is not. Which is a good deal, because judgement is the part that took you an afternoon to write down and the plumbing is the part that took you four lines.

Moving a skill to another tool

The practical procedure is short.

1. Take the body, not the folder. Open SKILL.md and separate the instructions from anything naming a specific tool surface.
2. Put it where that tool looks. Its documentation names one directory or file. If the tool supports several instruction files, one per skill keeps them reviewable; if it supports only one, append under a clear heading.
3. Reconsider the trigger. In an always-loaded tool, the description is documentation rather than a matcher, and length now costs you on every request. Trim aggressively.
4. Drop the plumbing. Delete the hook config and the slash commands rather than leaving instructions the tool cannot act on — stale directions are worse than absent ones, because the model may try to follow them.
5. Test with a realistic request. Same check as anywhere: phrase a task the way you normally would and see whether the behaviour changed.

Fifteen minutes for a skill you did not have to write. The authoring guide covers the reverse direction — writing a body that was portable to begin with.

Most skills never say

Here is what the catalog looks like on this question. Across the skills we index, only about one in fifteen names more than one agent, and over eight in ten name none at all.

That is not a compatibility finding. It is an authoring habit. People write against the tool open on their desk, and it does not occur to them to mention which one — a skill full of Python testing conventions works fine in four agents and advertises support for zero. The gap between “declared” and “actually portable” is enormous, and it runs almost entirely in your favour.

Two consequences worth acting on:

As a consumer, do not filter on declared compatibility alone. A skill that mentions only Claude Code is very often a plain instructions skill that will work wherever you put it. Read the body and judge whether it names any tool surface — that is the real test. Our alternatives pages collect skills by declared compatibility, which is a useful starting shortlist rather than an exhaustive one.

As an author, say it. One line of frontmatter makes your skill findable by everyone who does filter:

compatibility: [claude-code, cursor, codex]

If the body contains nothing tool-specific, that line is honest and it roughly quadruples the audience that can discover the work.

Writing for more than one tool

If you expect your skill to be used across agents, a few choices make it hold up.

Keep the body tool-neutral. Write “run the test suite”, not “use the /test command”. The former works everywhere; the latter breaks in three places out of four.

Separate the plumbing visibly. Put anything tool-specific under its own heading, or in its own file, so a reader porting the skill knows exactly what to discard:

api-conventions/
├── SKILL.md              ← portable: the conventions
├── claude-code.md        ← hooks and slash commands
└── examples/handler.ts

Do not assume a permission model. One agent asks before running a command; another runs it. Instructions written on the assumption of a confirmation prompt behave differently where there is none — which is also a safety consideration, covered in vetting a skill before you install it.

Keep it short. Portable also means it might be loaded unconditionally somewhere. A tight 80-line skill survives that; a 400-line one becomes somebody’s context problem.

The bottom line

Skills are portable because they are unglamorous — a folder, a Markdown file, and some frontmatter. Nothing about the substance of a good skill is tied to one vendor, and the part that is tied to one vendor is usually four lines you can delete.

Which means a skill library is a fairly durable investment. If you switch agents next year, the conventions you wrote down move with you; the wiring gets redone in an afternoon.

Browse by the tool you actually use:

• Skills for Cursor
• Skills for Codex
• Skills for GitHub Copilot
• Skills for Gemini CLI
• The full catalog — every listing links to its source so you can read the body before committing