Write a Skill Once, Load It in Six Clients: Agent Plugins 1.0 Ships Without Anthropic

Teaching a coding agent your own procedure means writing a skill: one folder holding a SKILL.md with instructions like "when opening a PR, review in this order." Reaching an external tool or an internal database means attaching an MCP server. Both pieces already have shared specs, so either one works in any client.

Shipping the two together as one bundle is where it broke. Claude Code keeps its manifest at .claude-plugin/plugin.json and reads MCP config from .mcp.json. VS Code, Cursor, and Kiro each look in a different place under a different name. The same skill bundle had to be repackaged once per tool. The AWS open source blog described the situation as building for one client and then rewriting it for another.

On August 6, Agent Plugins 1.0.0 was published. OpenAI, Microsoft, AWS, Anysphere (the company behind Cursor), GitHub, and Vercel released it jointly, and Google announced the same day that it was joining as a Core Maintainer. The spec standardizes directory layout and file names. That is the whole job.

A plugin is one directory

The entire spec comes down to three files.

my-plugin/
├── plugin.json          # required. name and spec version
├── skills/              # optional. skills/{name}/SKILL.md
│   └── code-review/
│       └── SKILL.md
├── mcp.json             # optional. MCP server declarations
└── com.example.client/  # optional. client-specific namespace

plugin.json has exactly two required fields.

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

version, description, author, license, and keywords are all optional. The root is a closed schema, though, so any key the spec does not define fails validation. That is the guard against a vendor quietly growing its own fields until the format forks. Client-specific data goes in a reverse-domain namespace such as com.example.client, and a client that does not recognize that namespace must ignore it rather than validate it.

Skill discovery is deliberately shallow. A subdirectory directly under skills/ containing a SKILL.md counts as one skill, and the spec states that clients must not recurse into deeper descendants looking for more. A malformed skill is skipped and the rest keep loading. The spec writes this out as a resilience rule: a failure in one component must not block the loading of other independent components.

mcp.json covers three transports: stdio, streamable-http, and legacy sse. A client has to support at least one of the first two, and sse is optional. When a local process is launched, the client must pass two environment variables, PLUGIN_ROOT (the plugin's absolute path) and PLUGIN_DATA (a client-managed persistent data path). ${PLUGIN_ROOT} substitution applies once, non-recursively, and only inside args, env values, and cwd. command is treated as a single token with no shell parsing.

Both ingredients came from Anthropic

The only new thing here is the wrapper. The two specs inside it are unchanged and already in use.

• MCP: the tool-connection standard Anthropic published in November 2024
• Agent Skills: Anthropic's SKILL.md-based skill format

Anthropic appears neither among the founding members nor on the technical steering committee. The initial Core Maintainers are Amazon, Cursor, Microsoft, OpenAI, and Vercel, with Google added. The spec's lead author is Jonathan Hefner of Vercel, and Google's representative is Kevin Hou of DeepMind. In an August 7 article, The Decoder noted that Anthropic authored both underlying standards yet stayed out of this effort, and instead added a plugin system of its own to Cowork, its desktop agent tool.

The governance document makes clear that this roster is a design choice rather than an accident. No single vendor may hold a majority of Core Maintainer seats, every position is held by an individual rather than a company, and the name, logo, domain, and GitHub organization are held in trust by a neutral entity the committee designates. The spec is CC-BY-4.0 and the code is Apache 2.0. The whole arrangement avoids the shape where one company owns a format and everyone else follows. For anyone who lived through the MCP spec forcing a stateless migration in a single unilateral revision, the motivation is not hard to guess.

Hooks and subagents do not travel

The spec lists its non-goals out loud. Commands, hooks, subagents, and LSP servers were left out of v1 on the grounds that they are too client-specific, and registry-based distribution, OAuth and credential storage, and subprocess sandboxing were dropped as well. As The Decoder summarized it, the standard covers packaging and discoverability and leaves marketplaces, permissions, and the runtime environment alone.

Google's blog drew the line this way: packaging is one job, and discovering plugins and getting them to users is another.

Set it beside the Claude Code plugin format and what ports versus what does not becomes clear.

The skill directory rule is already identical, character for character. Move the manifest and drop the leading dot on mcp.json and half of a Claude Code plugin is an Agent Plugin. Going the other way, a plugin that blocks tool calls through hooks or splits work across subagents has nowhere to land. The more of your team's rules live in hooks, the smaller the portable fraction.

What you can use today

The spec is public with no regional restrictions, and there is no waitlist, application, or approval step. All you need is a client that reads the format.

AWS has curated more than 30 skills across several plugins in its Agent Toolkit and opened them as Agent Plugins-compatible. Google's Data Agent Kit ships plugins that connect to BigQuery, Spanner, and Cloud SQL. If you are consuming plugins rather than authoring them, almost everything installable right now comes from those two.

If your team already has Claude Code skills or plugins, leave skills/ untouched, copy the manifest to a root plugin.json and .mcp.json to mcp.json, and open that copy in Cursor or VS Code. Half an hour gives you the list of which parts of your plugin port cleanly and which parts stay pinned to hooks and subagents. That list is what tells you whether this spec is worth anything to your team.