# Agent Skills support: which AI clients read SKILL.md

> A compatibility matrix for the Agent Skills format, checked on August 20, 2026. Eleven clients whose own documentation states they read SKILL.md, with the exact directories each one names, thirty-six more listed on the agentskills.io showcase, and the behavior nobody has documented.

- Canonical URL: https://www.skillsboard.sh/agent-skills-support
- Markdown URL: https://www.skillsboard.sh/agent-skills-support.md
- Publisher: Skills Board (https://www.skillsboard.sh)
- Published: 2026-08-20
- Last updated: 2026-08-20
- Topics: agent skills support, skill compatibility, skill format, cross-agent sharing

Every answer to this question is either a logo wall or a shrug. A logo wall tells you a product is on a list. It does not tell you what the product actually reads, where it looks for it, or who said so. This page separates those two things and keeps them separated all the way down.

Two levels of evidence appear here, labelled on every row. The first is vendor documented: the client's own documentation says it reads SKILL.md, and we fetched and read that documentation on August 20, 2026. Eleven clients cleared that. The second is showcase listed: the client appears on the Agent Skills client showcase, which had forty-six entries on the same date, and we did not open its documentation. Thirty-six entries sit in that second group.

The criteria come first, before any table, because a compatibility matrix without a stated bar is a list of opinions. After the matrices there is a section on what is not documented anywhere, which on this topic is larger than most pages admit.

## In short

Eleven clients document reading SKILL.md in their own published documentation: Claude Code, the Claude apps and Claude API, Claude Cowork, Codex, Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenCode, goose, and Amp. The Agent Skills client showcase listed forty-six products on August 20, 2026, so being on the showcase and having vendor documentation you can read are different claims, and this page marks which is which on every row.

Support is not one thing. Every one of the eleven documented clients loads the same two required frontmatter fields, name and description, and defers the body until the skill is used. Beyond that they diverge on which directories they scan, which extra frontmatter fields they honor, whether they ask for consent before activation, and what they do with a field they do not recognize.

The one directory nearly all of them name is the vendor-neutral one. Eight of the eleven documented clients scan .agents/skills in a project and ~/.agents/skills in a home directory. Claude Code is the notable absence: its documentation lists .claude/skills and ~/.claude/skills and never mentions the neutral path.

Nobody publishes a conformance test. There is no certification, no version number a client claims to implement, and no published result showing that a given skill behaves the same in two products. Support here means documented reading of the file, which is the strongest claim the public record actually supports.

## What counts as support on this page

Five rules, applied in order. A client that fails the first rule does not appear in the documented matrix no matter how widely it is described as compatible, and a behavior that fails the third is written down as undocumented rather than quietly asserted.

### Rules

- **1. The vendor said it, in its own documentation:** The evidence has to be a page the vendor publishes about its own product: a docs site, a manual, a reference. A conference talk, a changelog entry in someone else's repository, a third-party blog post, or a GitHub issue does not qualify. This is the rule that separates the eleven from the rest, and it is deliberately strict, because the interesting failure mode on this topic is a claim that circulates without a source.
- **2. The documentation states that the client reads SKILL.md:** Naming the Agent Skills standard is not enough on its own, and neither is having a feature called skills. The page has to describe reading a SKILL.md file, or reading the Agent Skills format, as something the product does. One client in the documented group, GitHub Copilot, never writes the string SKILL.md on its concept page, and that is recorded on its row rather than smoothed over.
- **3. We fetched the page on August 20, 2026:** Every source in the list below was requested on that date and read. Where a URL redirected, the destination is what we read and what we cite. Where a URL returned a 404, that is reported instead of being replaced with a guess. Two links published on the client showcase itself did not resolve to what they claimed, and both are named in the notes rather than silently corrected.
- **4. Only directories the vendor names are listed:** The directory column repeats the paths the documentation prints. It does not include a path because a user reported it works, because the product is built on something that reads that path, or because it would be reasonable. If a client is widely believed to read a directory and its documentation does not say so, that gap goes in the section on what is not documented.
- **5. Silence is recorded as silence:** Undocumented is not the same as unsupported. When a vendor page says nothing about a behavior, this page says the page says nothing. It does not infer the answer from the source code, from another product by the same vendor, or from the specification. The specification describes a format, not an obligation, and no client is bound to implement all of it.

Popularity is not a criterion. Neither is install count, star count, or how often a product is mentioned in a discussion. None of those are evidence that a file gets read, and all of them are easier to find than the thing that matters.

The showcase matrix further down uses a weaker bar on purpose, and says so in its own heading. Those thirty-six rows record that a product self-nominated to a public list and whether that listing carries a setup link. They are a starting point for your own check, not a substitute for one.

For what the format itself defines, rather than who reads it, see [our page on the Agent Skills standard](https://www.skillsboard.sh/agent-skills).

## Clients whose own documentation states they read SKILL.md

Eleven entries, each backed by a first-party page fetched on August 20, 2026 and listed in the sources at the foot of this page. The directory column prints only the paths that documentation names.

| Client | What the vendor documents | Documented skill locations |
| --- | --- | --- |
| Claude Code | The skills page opens by stating that Claude Code skills follow the Agent Skills open standard, which works across multiple AI tools, and that Claude Code extends the standard with additional features. It documents a precedence order across enterprise, personal, and project levels, plugin skills under a plugin-name namespace, and live detection when a SKILL.md file changes on disk. | ~/.claude/skills/, .claude/skills/ in the start directory and every parent up to the repository root, plugin skills/, and an enterprise managed-settings path |
| Claude apps and the Claude API | Anthropic's overview names three surfaces where skills work: the Claude API, Claude Code, and claude.ai. API skills are referenced by a skill identifier or uploaded through the Skills API and run inside the code execution container. The same page states that custom skills do not sync across surfaces, which is the detail most teams get wrong. | No filesystem path outside Claude Code. Zip upload through settings on claude.ai, and the /v1/skills endpoints on the API |
| Claude Cowork | Documented on the Claude Code skills page rather than a page of its own. It states that Cowork sessions do not read the personal skills directory on your machine, and that both interactive and scheduled Cowork sessions load the skills enabled for your claude.ai account, synced at the start of the session. | Skills enabled for the claude.ai account, managed from Customize in the desktop app sidebar or from the skills settings on claude.ai |
| Codex | OpenAI documents that a skill is a directory with a SKILL.md file that must include name and description, that skills build on the open agent skills standard, and that Codex loads the full instructions only when it decides to use a skill. Availability is stated as the Codex CLI, the IDE extension, and the Codex app. | .agents/skills scanned from the working directory up to the repository root, $HOME/.agents/skills, /etc/codex/skills, and skills bundled by OpenAI |
| Cursor | Cursor calls Agent Skills an open standard twice on the page and links the specification. It walks a skills root recursively and picks up any SKILL.md it finds, scopes skills in nested project directories to files inside that directory, and is the only documented client that names another vendor's directories as a compatibility feature in both directions. | .agents/skills/, .cursor/skills/, ~/.agents/skills/, ~/.cursor/skills/, plus .claude/skills/, .codex/skills/, ~/.claude/skills/, and ~/.codex/skills/ for compatibility |
| GitHub Copilot | GitHub's concept page calls the Agent Skills specification an open standard used by a range of different AI systems, and lists the surfaces: the Copilot cloud agent, Copilot code review, the Copilot CLI, the Copilot app, and agent mode in Visual Studio Code and JetBrains IDEs. The page never writes the string SKILL.md, which is why the VS Code row exists separately. | Project: .github/skills, .claude/skills, .agents/skills. Personal: ~/.copilot/skills, ~/.agents/skills |
| VS Code | The VS Code documentation is where the concrete rules live for the Copilot family. It states that skills are stored in directories with a SKILL.md file, links the specification directly, and adds a setting for extra project skill locations plus an extension contribution point that registers a skill from an extension. | Project: .github/skills/, .claude/skills/, .agents/skills/. Personal: ~/.copilot/skills/, ~/.claude/skills/, ~/.agents/skills/ |
| Gemini CLI | Gemini CLI describes a skill as a self-contained directory based on the Agent Skills open standard. It adds a consent step the specification does not define: a confirmation prompt naming the skill, its purpose, and the directory path it will gain access to, shown before the skill activates. | ~/.gemini/skills/ with the ~/.agents/skills/ alias, and .gemini/skills/ with the .agents/skills/ alias. Within a tier the neutral alias takes precedence |
| OpenCode | OpenCode documents SKILL.md definitions loaded on demand through a native skill tool, and publishes a closed frontmatter allowlist of name, description, license, compatibility, and metadata, with unknown fields ignored. It adds an allow, deny, or ask permission model per skill that the specification does not define. | .opencode/skills/, ~/.config/opencode/skills/, .claude/skills/, ~/.claude/skills/, .agents/skills/, ~/.agents/skills/ |
| goose | goose documents placing a SKILL.md file inside a named subdirectory, and describes its skills as compatible with Claude Desktop and other agents that support Agent Skills rather than claiming to implement the standard. Skills arrive through a Skills platform extension enabled by default, not through the core agent. | ~/.agents/skills/, .agents/skills/, and plugin directories, with .goose/skills/, .claude/skills/, and ~/.claude/skills/ kept for backward compatibility |
| Amp | Amp's manual documents a directory containing a SKILL.md file with YAML frontmatter, and that name and description stay visible to the model while the rest of the file loads only on invocation. It never uses the words standard or specification, and calls the Claude paths Claude-compatible locations. A setting turns those paths off. | ~/.config/agents/skills/, ~/.agents/skills/, ~/.config/amp/skills/, .agents/skills/ and .claude/skills/ in the project and parent directories, ~/.claude/skills/, a plugin cache, and configured search paths |

Read the middle column and the pattern is clear: every one of the eleven loads name and description first and the body later, and after that they stop agreeing. Three add a permission or consent step. Two publish a closed list of frontmatter fields. Four add frontmatter fields of their own that no other client is documented to act on, named one by one in the compatibility gaps below. One delivers the whole feature through an optional extension.

Two of the eleven are not agents at all in the ordinary sense. The Claude API row describes skills that run inside a code execution container and are referenced by an identifier, and the Cowork row describes skills that arrive by account sync. Neither reads a folder you can commit to a repository, which matters if your plan for distributing a skill is a git repository.

The Claude row and the Claude Code row are separate for a reason the vendor documentation states outright: custom skills do not sync across Anthropic's own surfaces. A skill uploaded on claude.ai is not present in Claude Code, and a skill in a project directory is not present in a claude.ai conversation.

The Claude Code side of this row has a page of its own in [our explainer on Claude skills](https://www.skillsboard.sh/claude-skills), including the format and the install paths.

## Listed on the client showcase, not read by us today

The Agent Skills client showcase carried forty-six entries on August 20, 2026. Ten of them are covered in the matrix above. These are the other thirty-six, in the order the showcase publishes them. A row here means the product appears on that page and, in all but one case, links its own setup instructions. It does not mean we opened those instructions.

| Client | How the showcase describes it | Setup instructions |
| --- | --- | --- |
| Junie | An LLM-agnostic coding agent built on the IntelliJ Platform | Linked |
| ZeroClaw | An open-source, Rust-first agent runtime for local personal agents | Linked |
| Autohand Code CLI | An autonomous coding agent that runs in the terminal | Linked |
| OpenHands | An open platform for cloud coding agents | Linked |
| Mux | Parallel coding agents, each in an isolated workspace | Linked |
| Letta | A platform for stateful agents with long-lived memory | Linked |
| Firebender | An Android-native coding agent that tests in the emulator | Linked |
| Piebald | A desktop and web app for agentic development | None listed |
| Factory | An AI-native development platform spanning IDE to CI/CD | Linked |
| pi | A minimal terminal coding harness | Linked |
| Databricks Genie Code | An agent purpose-built for data work in Databricks | Linked |
| Agentman | An agentic healthcare platform for revenue cycle workflows | Linked |
| TRAE | An adaptive AI IDE | Linked |
| Spring AI | A framework for adding AI functionality to Spring applications | Linked |
| Roo Code | A multi-agent coding extension for the editor | Linked |
| Mistral AI Vibe | A command-line coding assistant powered by Mistral models | Linked |
| Command Code | A coding agent that adapts to a developer's coding taste | Linked |
| Ona | A platform for background agents running in the cloud | Linked |
| VT Code | An open-source coding agent with multi-provider failover | Linked |
| Qodo | An agentic code integrity platform for review and testing | Linked |
| Laravel Boost | Guidelines and skills for AI-assisted Laravel development | Linked |
| Emdash | A desktop app running parallel agents in git worktrees | Linked |
| Snowflake Cortex Code | An agent integrated into the Snowflake platform | Linked |
| Kiro | An agent built around spec-driven development | Linked |
| Workshop | A cross-platform coding agent as desktop, web, and CLI | Linked |
| Google AI Edge Gallery | An app for running open models on a mobile device | Linked |
| nanobot | A lightweight personal agent for terminal and messaging platforms | Linked |
| fast-agent | A framework for building and evaluating agents | Linked |
| bub | A hook-first Python framework for channel-native agents | Linked |
| Tabnine | An AI engineering platform with agentic workflows | Linked |
| Vita | Autonomous digital workers running on virtual desktops | Linked |
| Superconductor | A multiplayer workspace for a team and its coding agents | Linked |
| Deep Code | An open-source terminal assistant for DeepSeek models | Linked |
| Pulumi Neo | An agent that manages cloud infrastructure with Pulumi | Linked |
| Hermes Agent | A personal agent across CLI, desktop, and messaging platforms | Linked |
| OpenClaw | An open-source personal assistant that runs locally | Linked |

Thirty-five of these thirty-six publish a setup link. Piebald is the one entry on the whole showcase with no instructions URL and no source repository, so there is nothing to check even at this weaker level of evidence.

The showcase is a self-nomination list. A product is on it because someone submitted it, and the page carries no test result, no version claim, and no date for any entry. That is not a criticism of the list, which is useful for discovery, but it is the reason these rows sit in their own matrix instead of the one above.

Two showcase links did not resolve to what the entry claimed when we followed them on August 20, 2026. The goose entry points at a documentation URL that returns a 404, because the project has moved to a new documentation domain under new stewardship. The Cursor entry points at a path that redirects to a different one. Both are minor, and both are the reason a link on a directory page is not the same evidence as a page you opened.

If you are picking a skill rather than a client, the selection criteria are on [our register of Claude skills](https://www.skillsboard.sh/best-claude-skills).

## Which directory reaches which clients

Support is decided in practice by where a file sits, not by whether a logo appears on a list. This table inverts the matrix above: each row is a directory, and the clients named are the ones whose documentation prints that path. Only the eleven documented clients are counted here.

| Directory | Documented by | What that means |
| --- | --- | --- |
| .agents/skills/ | Codex, Cursor, Gemini CLI as an alias, OpenCode, goose, Amp, GitHub Copilot, VS Code | Eight of the eleven, and the single most widely documented project directory. It is the only repository path OpenAI's Codex documentation lists, and goose calls it the recommended standard location. Claude Code's documentation never mentions it. |
| ~/.agents/skills/ | Codex, Cursor, Gemini CLI as an alias, OpenCode, goose, Amp, GitHub Copilot, VS Code | The user-level counterpart, documented by the same eight. A personal skill placed here is visible to more documented clients than one placed anywhere else on the machine. |
| .claude/skills/ | Claude Code, Cursor, OpenCode, GitHub Copilot, VS Code, goose, Amp | Seven of the eleven, but only Claude Code treats it as its own. Cursor and OpenCode call it compatibility, goose calls it backward compatibility, and Amp calls it a Claude-compatible location and offers a setting that turns it off. |
| ~/.claude/skills/ | Claude Code, Cursor, OpenCode, VS Code, goose, Amp | Six of the eleven. GitHub's own concept page lists ~/.copilot/skills and ~/.agents/skills for personal skills and does not include this one, while the VS Code page does. The two Copilot pages differ on this row. |
| .codex/skills/ and ~/.codex/skills/ | Cursor only | Cursor documents reading both for compatibility. OpenAI's Codex documentation does not list either as a scan location, and names only the neutral, home, admin, and bundled locations. Whether Codex reads its own namespaced directory is not something its documentation answers. |
| Vendor-native project directories | .cursor/skills/, .opencode/skills/, .gemini/skills/, .github/skills/, .goose/skills/ | One client each, by definition. Useful when a skill is meant for one tool and would be noise in another, and a poor choice for anything a mixed team is supposed to share. |
| Administrative and managed locations | Claude Code managed settings, /etc/codex/skills | Two of the eleven document a path an administrator controls rather than a developer. Both sit above the personal and project levels in their own precedence rules. |
| No filesystem path at all | claude.ai, the Claude API, Claude Cowork | Three surfaces, across two of the eleven rows, never read a folder on your machine. Skills arrive by zip upload, by an API endpoint, or by account sync at the start of a session. A git repository is not a distribution channel for these three. |

The practical reading of this table is that .agents/skills and ~/.claude/skills between them cover every documented client that reads a filesystem at all, and neither one covers all of them alone. A repository that wants both audiences commits one and points the other at it, which several of these clients support through symlinks that their documentation mentions.

None of this is a guarantee that the same file behaves identically once it is found. The directory determines discovery. What happens after discovery depends on frontmatter handling, permission models, and context budgets, which vary and which the next section covers.

The working version of this, for a team that runs more than one agent, is [our guide to managing skills across Claude Code, Codex, and Cursor](https://www.skillsboard.sh/guides/manage-skills-across-claude-codex-cursor).

## What is not documented

Seven things this page cannot tell you, because no vendor publishes them. Each one is a place where a compatibility claim usually gets invented, so each one is stated as a gap instead.

### No client publishes a conformance result

There is no certification, no badge, and no published test run showing that a given client handles the format correctly. The specification links a reference library that validates a skill file, which checks the file rather than the client reading it. No documented client states which version of the specification it implements, and the specification does not carry a version number that a client could cite.

### Whether Codex reads its own namespaced directory

Cursor documents reading .codex/skills and ~/.codex/skills for compatibility. OpenAI's own skills documentation lists the neutral project path, the home path, an admin path, and bundled skills, and does not mention either .codex directory as a scan location. That is a silence, not a denial, and this page does not resolve it in either direction.

### What a client does with a frontmatter field it does not recognize

One documented client, OpenCode, states outright that unknown frontmatter fields are ignored. The others say nothing. Claude Code documents that fields outside the six spec fields cause a hard error when a skill is packaged or uploaded through other Anthropic paths, but that is a packaging rule rather than a statement about how another vendor's agent will read the same file.

### How vendor-specific fields behave elsewhere

Several documented clients add fields of their own. Claude Code documents a long list including model, effort, and hooks. VS Code documents an experimental field that runs a skill in a subagent. Amp documents a field that declares MCP servers. Cursor documents fields for path scoping and display. No vendor documents what happens when another vendor's agent encounters those fields.

### Whether a skill produces the same result in two clients

Discovery is documented. Behavior after discovery is not. Context budgets for the skill listing differ and two clients publish specific numbers that do not match. Permission models differ, from a per-activation consent prompt to no approval step at all. Nobody publishes a comparison, so a skill that works well in one client is evidence about that client only.

### How the showcase list is maintained

The client showcase does not publish an inclusion policy, a review step, a date for any entry, or a removal process. Forty-six entries appeared on August 20, 2026, and the count on any other date is a different fact. One entry carries no setup link at all, and at least one setup link no longer resolves, which suggests entries are not revalidated on a schedule.

### What support means for the three surfaces without a filesystem

claude.ai, the Claude API, and Claude Cowork all support skills according to Anthropic's own documentation, and none of them read a project directory. The documentation states that custom skills do not sync across surfaces, so a team using both Claude Code and Cowork maintains the same skill in two places. No vendor documents a supported way to keep those two copies aligned.

The one client that publishes what it does with a field it does not recognize, and the one with the fullest per-skill permission rules, is covered row by row in [our explainer on OpenCode skills](https://www.skillsboard.sh/opencode-skills).

## What a team does with this

A matrix is only useful if it changes a decision. For most teams it changes two: where the canonical file lives, and how a teammate on a different client finds out that the recommendation exists.

The first decision is the cheap one. Put the canonical SKILL.md in .agents/skills in the repository, because eight of the eleven documented clients scan it, and add whatever second path your Claude Code users need. That is a five-minute change and it removes most of the per-teammate friction.

The second decision is the one that actually costs something. Directories solve discovery for a repository somebody has already cloned. They do nothing for the teammate who has not, for the person on Cowork whose skills arrive by account sync, or for the colleague who asks in chat which skill to use for a task and gets a link that will be scrolled away by Thursday.

Skills Board is a web application where a team keeps and shares the AI skills it recommends. Each saved entry keeps its original source visible, and a teammate chooses how to use it: open the repository, copy an install command that suits their client, or download the latest files as a ZIP. That last option is what makes it usable by the three surfaces above that never read a folder.

### Options

- **Open the source:** The repository the skill actually comes from, so a teammate can read the SKILL.md before running anything. This is the path for the technical reviewer who wants to see the file, not a summary of it.
- **Copy an install command:** A command that fits the client the teammate is running, without assuming everyone on the team uses the same one. Nothing here certifies that the skill behaves identically across clients, and this page is the reason that caveat exists.
- **Download a ZIP:** The latest files from the source at download time. This is the route for the surfaces with no filesystem to commit to, where a skill arrives as an upload rather than as a folder in a repository.
- **Search from a connected agent:** An MCP-compatible client can search the team's saved skills and retrieve an install command in the session, so the answer to which skill to use arrives where the question was asked.

### Limits

- A saved skill is a team recommendation. It is not a security review, an approval, or a compatibility certification, and nothing on this page turns a documented directory into a guarantee that a skill runs correctly.
- Skills Board points at the latest version available from the saved source. It does not pin or preserve historical versions, so a skill that changes upstream changes for everyone who opens it next.
- A ZIP contains the latest files from the source at download time. It does not guarantee installation in every client, and the frontmatter differences in the section above are exactly why that guarantee cannot be made.

The step before this one, choosing what to recommend at all, is covered in [our guide to sharing AI agent skills with your team](https://www.skillsboard.sh/guides/share-agent-skills-with-your-team).

## Frequently asked questions

### Which AI agents support Agent Skills today?

Eleven clients document reading a SKILL.md file in their own published documentation: Claude Code, the Claude apps and API, Claude Cowork, Codex, Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenCode, goose, and Amp. A further thirty-six products appeared on the Agent Skills client showcase on August 20, 2026 without being checked here.

### What counts as agent skills support on this page?

Support means the vendor's own documentation states that its client reads SKILL.md or the Agent Skills format, and that we fetched and read that page on August 20, 2026. A blog post, a talk, or an entry on a directory list does not qualify. Undocumented behavior is recorded as undocumented rather than assumed.

### Does every client on the showcase read a SKILL.md file the same way?

No, and no vendor claims it does. Every documented client loads name and description first and the body later, then they diverge on directories, extra frontmatter fields, consent prompts, and context budgets. There is no published conformance test, so a skill that works in one client is evidence about that client only.

### Will one SKILL.md work in Claude Code, Codex, and Cursor unchanged?

The required parts travel. All three document reading a directory with a SKILL.md file whose frontmatter carries name and description. What does not travel is the vendor-specific frontmatter, and the location: Codex documents only the neutral path, Claude Code documents only its own, and Cursor documents both plus its own.

### Which directory gives a skill the widest client support?

The vendor-neutral one. Eight of the eleven documented clients name .agents/skills in a project and the matching path in a home directory, which is more than any other location reaches. Claude Code is the significant exception, since its documentation lists only its own directories and never mentions the neutral path.

### Do the Claude apps support skills the same way Claude Code does?

No. Anthropic documents three surfaces, and only Claude Code reads skills from the filesystem. On claude.ai a skill is uploaded as a zip in settings, and through the API it is referenced by identifier or uploaded through the Skills API. The same documentation states that custom skills do not sync across surfaces.

### Does GitHub Copilot support agent skills in VS Code?

Both vendors document it. GitHub lists agent mode in Visual Studio Code among the supported surfaces, and the VS Code documentation states that skills are stored in directories with a SKILL.md file. The two pages differ slightly on personal directories, so the VS Code page is the more specific source for a developer.

### What happens to a frontmatter field a skill's client does not support?

Mostly undocumented. OpenCode is the one documented client that states unknown fields are ignored. Claude Code documents that fields outside the six specification fields cause a hard error when a skill is packaged or uploaded through other Anthropic paths, which is a packaging rule rather than a cross-client guarantee.

## Sources

- [Agent Skills specification](https://agentskills.io/specification): The required directory shape, the six frontmatter fields and their constraints, the progressive disclosure stages, and the reference library that validates a skill file.
- [Agent Skills: overview](https://agentskills.io): The format described as an open standard originally developed by Anthropic and released for the wider ecosystem, with the three-stage discovery, activation, and execution model.
- [Agent Skills: client showcase](https://agentskills.io/clients): The self-nomination list of agent products that support the format. Forty-six entries when fetched on August 20, 2026, forty-five of them carrying a setup instructions link.
- [Claude Code: skills](https://code.claude.com/docs/en/skills): The enterprise, personal, project, and plugin locations, the precedence order, the frontmatter fields Claude Code adds beyond the specification, and the statement that Cowork sessions load skills synced from the claude.ai account.
- [Anthropic: Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview): The three surfaces where skills work, the Skills API endpoints and the code execution requirement, the zip upload path on claude.ai, and the statement that custom skills do not sync across surfaces.
- [OpenAI: skills for Codex](https://developers.openai.com/codex/skills): The scan locations from the working directory up to the repository root, the home, admin, and bundled locations, the surfaces where skills are available, and the published budget for the initial skill listing.
- [Cursor: skills](https://cursor.com/docs/skills): The four native directories, the four compatibility directories belonging to Claude and Codex, the recursive discovery of nested skills, and the frontmatter fields Cursor documents.
- [GitHub: about agent skills](https://docs.github.com/en/copilot/concepts/agents/about-agent-skills): The project and personal directories, and the list of Copilot surfaces where agent skills apply. The page describes the specification as an open standard and never writes the file name itself.
- [Visual Studio Code: agent skills](https://code.visualstudio.com/docs/agent-customization/agent-skills): The project and personal directory tables, the setting for additional skill locations, the extension contribution point, and the frontmatter fields VS Code adds beyond the specification.
- [Gemini CLI: skills](https://geminicli.com/docs/cli/skills): The four discovery tiers with the neutral alias taking precedence inside a tier, and the consent prompt shown before a skill activates, which the specification does not define.
- [OpenCode: agent skills](https://opencode.ai/docs/skills): The six discovery paths, the closed frontmatter allowlist with unknown fields ignored, and the per-skill allow, deny, or ask permission model.
- [goose: using skills](https://goose-docs.ai/docs/guides/context-engineering/using-skills): The recommended neutral locations, the backward-compatible Claude and goose directories, and the Skills platform extension that provides the feature. The URL published on the client showcase returns a 404 and this is where it now lives.
- [Amp: owner's manual](https://ampcode.com/manual): The eleven-entry precedence list, the setting that disables the Claude-compatible locations, and the two frontmatter fields Amp adds. The manual makes no conformance claim to the specification.

## Related resources

- [How to manage AI skills across an organization](https://www.skillsboard.sh/manage-ai-skills)
- [Agent Skills: the open standard](https://www.skillsboard.sh/agent-skills)
- [Cursor skills: what they are and how to use them](https://www.skillsboard.sh/cursor-skills)
- [Codex skills: what they are and how to use them](https://www.skillsboard.sh/codex-skills)
- [OpenCode skills: what they are and how to use them](https://www.skillsboard.sh/opencode-skills)
- [Claude Cowork skills](https://www.skillsboard.sh/cowork-skills)
- [AGENTS.md vs SKILL.md](https://www.skillsboard.sh/agents-md-vs-skill-md)
- [Manage skills across Claude Code, Codex, and Cursor](https://www.skillsboard.sh/guides/manage-skills-across-claude-codex-cursor)