Do Claude Skills Work in Codex, Cursor and Gemini CLI?

A SKILL.md file you wrote for Claude Code will load in Codex, Cursor, Gemini CLI, OpenCode, and GitHub Copilot. The format is shared. What isn't shared is the folder each agent looks in, and that one detail is why a skill that works perfectly in one tool is invisible in the next.

Anthropic launched Agent Skills in October 2025 and published the format as an open standard that December, now maintained at agentskills.io. Adoption moved fast. OpenCode merged support in December 2025, GitHub shipped it for Copilot on December 18, Gemini CLI switched it on by default in January 2026, and Cursor added it in version 2.4 on January 22. The agentskills.io client showcase now runs to dozens of tools, Goose, Amp, Kiro, Roo Code, and OpenHands among them.

So the question in the title has a short answer: yes, mostly. The rest of this article is the "mostly", checked against each vendor's own documentation in September 2026.

Where each agent looks for skills

Read the last two columns together and the problem is plain. No single directory works everywhere. .claude/skills/ misses Codex and Gemini CLI. .agents/skills/ misses Claude Code, whose skills documentation doesn't mention that path at all.

The Copilot row has one wrinkle: its docs list .claude/skills for project skills, but for personal skills they name only ~/.copilot/skills and ~/.agents/skills.

The fix: one real folder, one symlink

Keep the skill files in .agents/skills/, since five of the six agents read it, and point Claude Code at the same folder:

mkdir -p .agents/skills .claude
ln -s ../.agents/skills .claude/skills

Claude Code's docs confirm that a skill folder can be a symlink to a directory elsewhere on disk, and that it loads the skill once even when several locations point at it. For personal skills, do the same thing under your home directory with ~/.agents/skills and ~/.claude/skills.

On Windows, creating symlinks needs Developer Mode or an elevated shell, and git only checks them out as links with core.symlinks=true. If your team is mixed, the lower-friction option is a short script in the repo that copies .agents/skills/ into .claude/skills/, with the copy listed in .gitignore.

If Claude Code is the only agent you care about now but you expect to try others, start with this layout anyway. Moving thirty skills later is more annoying than creating one symlink today.

Frontmatter: write to the spec, not to Claude Code

The open spec defines six frontmatter fields:

Those extras fail in three different ways depending on where the skill goes:

1. Other agents usually ignore them. OpenCode's docs say it recognizes the spec fields and ignores unknown ones. Your skill loads, but a skill that relied on disable-model-invocation: true to stay manual-only will now fire on its own. 2. Some agents honor a subset. VS Code's Copilot docs support argument-hint, user-invocable, disable-model-invocation, and an experimental context: fork. Cursor supports paths and disable-model-invocation. Partial support is harder to reason about than none. 3. Anthropic's own upload paths reject them. claude.ai skill uploads, the Skills API, and package_skill.py from anthropics/skills accept only the six spec fields. Anything else fails with Unexpected key(s) in SKILL.md frontmatter.

Point 1 is the one to watch. A deploy skill you made manual-only in Claude Code can become auto-triggered in another agent without any warning. For skills with side effects, write the guard into the body as well ("Only run this when the user explicitly asks to deploy") so it survives the trip.

On description length, write to 1,024 characters. That's the spec's hard limit. Claude Code's listing cap is 1,536 characters, and Codex caps its whole skills list at 2% of the context window, trimming descriptions when it runs over. A description that fits the spec fits everywhere.

Body features that don't travel

Frontmatter isn't the only Claude Code dialect. Two body features are specific to it:

• Dynamic context injection. A line like ` !git diff HEAD runs the command and pastes its output into the skill before Claude reads it. Claude Code's docs say this doesn't work on claude.ai or through the API, and other agents will show the line as literal text.
• String substitutions such as $ARGUMENTS and ${CLAUDE_SKILL_DIR}. Elsewhere these arrive unexpanded.

If a skill needs the current diff, tell the agent to run git diff HEAD as a step. It costs one tool call and works in every client.

The spec treats scripts/, references/, and assets/ as optional folders and says which languages work "depend on the agent implementation." In practice every agent runs scripts through its own shell tool, which means:

• A Python script needs Python on the machine, in whatever version the script assumes. Say so in compatibility ("Requires Python 3.10+ and pandas").
• Agents run commands non-interactively. A script that stops to ask a question will hang or fail.
• Tool names in allowed-tools differ between agents. Bash(git:*) Read means something to Claude Code and possibly nothing to the next client.
• Codex adds an optional agents/openai.yaml sidecar for invocation policy and tool dependencies. Other agents ignore it, which is harmless, but it's where Codex-only settings belong.

---
name: release-notes
description: Drafts release notes from merged pull requests since the last git tag. Use when the user asks for release notes, a changelog entry, or a summary of what shipped.
license: MIT
compatibility: Requires git and the GitHub CLI (gh) authenticated.
metadata:
  version: "1.2"
---

# Release notes

Only run when the user asks for release notes or a changelog.

1. Run `git describe --tags --abbrev=0` to find the last tag.
2. Run `gh pr list --state merged --search "merged:>=<tag date>"` to list merged PRs.
3. Group changes into Features, Fixes, and Internal.
4. Write the notes in the format shown in `references/format.md`.

Everything in it is spec-level. The manual-only guard sits in the body. The prerequisites sit in compatibility. No command injection, no substitutions. You can run skills-ref validate from the agentskills repo to check the frontmatter before you share it.

Anthropic's own Frontend Design skill uses only name, description, and license, so it drops into any of the six agents as-is. Check licenses before you copy anything from that repo, though. The README says many of its skills are Apache 2.0, but the document skills (PDF, DOCX, XLSX, PPTX) are source-available, and their frontmatter says license: Proprietary.

Write skills to the open spec, store them in .agents/skills/, and symlink .claude/skills/ to it. That gets one copy of each skill working in Claude Code, Codex, Gemini CLI, OpenCode, Copilot, and Cursor. Reach for Claude Code's extra frontmatter only when a skill will never leave Claude Code, and put any safety guard in the body where every agent will read it.

Yes. Codex reads the same SKILL.md format but looks in .agents/skills/ and ~/.agents/skills/, not .claude/skills/. Move the skill folder there or symlink one location to the other. Claude-only frontmatter fields won't take effect in Codex.

Not according to its current documentation, which lists .claude/skills/ and ~/.claude/skills/ plus plugin, enterprise, and --add-dir locations. Symlink .claude/skills to .agents/skills` to share one copy.

What happens to Claude Code-only frontmatter in other agents?

It depends on the destination. OpenCode ignores unknown fields, VS Code and Cursor honor a few, and claude.ai uploads and the Skills API reject the skill with an "Unexpected key(s)" error. Stick to name, description, license, compatibility, metadata, and allowed-tools for portable skills.

Is Agent Skills an official open standard?

Anthropic developed the format and published it as an open standard in December 2025. The specification lives at agentskills.io, with the spec and reference validator in the agentskills/agentskills GitHub repository.

Do skill scripts work the same in every agent?

The instructions do; the environment doesn't. Scripts run through each agent's shell with whatever runtimes are installed on your machine, so declare requirements in the compatibility field and avoid scripts that prompt for input.