/ ecosystem

Five vendors agreed on a plugin folder. Distribution is still your problem.

Agent Plugins 1.0 gives skills and MCP servers one folder shape across six clients, then leaves versioning, pinning, and installation to someone else.

What Agent Plugins standardizes, and what it leaves out A plugin folder with plugin.json, skills, and mcp.json feeds into six clients. Version pinning, a registry, and installation sit outside the spec, unfilled. plugin/ plugin.json skills/greet/ SKILL.md mcp.json → ChatGPT · Codex · Cursor Copilot · Kiro · VS Code Claude Code: own format, .claude-plugin/plugin.json out of scope: dependencies, version pinning, registries, installation, checksums
The spec fixes the shape of the folder. What fills it, pins it, and installs it is left to whoever consumes it - and Claude Code reads a differently-shaped folder entirely.

On August 6, 2026, five companies that normally compete for the same developer attention published a joint specification instead. Agent Plugins 1.0.0, announced on Vercel's blog, defines a single folder format for packaging Agent Skills and MCP servers so one plugin can be built once and read by more than one AI coding tool. It is a narrow spec, and the gap it leaves on purpose is exactly the ground skillfold's lockfile already covers - which makes it worth reading closely rather than taking on faith.

What the spec actually standardizes

A plugin is a directory with a plugin.json manifest at its root. Per the specification, only two fields are required:

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

Everything else - version, description, author, homepage, repository, license, keywords - is optional. Two component types sit alongside the manifest: a skills/ directory, where each immediate subdirectory containing a SKILL.md file is treated as one skill built to the separate agentskills.io format, and an mcp.json file declaring stdio or HTTP-based MCP servers under a mcpServers key. Client-specific behavior can be layered on through reverse-domain namespaces under an extensions field, so a given client can add its own metadata without breaking the portable core.

The project's MAINTAINERS file names five Core Maintainers on the Technical Steering Committee: Clare Liguori (Amazon), Roshan Sadanani (Cursor), Harald Kirschner (Microsoft), Gav Verma (OpenAI), and Jonathan Hefner (Vercel, who holds the Lead Core Maintainer role). Vercel's launch post states the format has support at launch from ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code.

What it deliberately does not standardize

The specification is explicit about its own boundary. It says nothing about how a plugin declares a dependency on another plugin or skill, how a version gets pinned once a client has fetched one, where a plugin comes from (a registry, a git URL, a local path are all left to the client), or how a client verifies that what it downloaded is what the author published. There's no lockfile-equivalent anywhere in the spec, and no checksum field on a plugin as a whole.

That's a defensible scope decision, not an oversight - a portable folder shape is a real, useful thing to agree on across five companies, and bundling a full package-manager story into the same effort would have made consensus much harder to reach. But it means "Agent Plugins 1.0 ships" does not mean the distribution problem is solved. It means the folder that gets distributed now has an agreed shape, and every question of how it moves from a publisher's repository to your machine - and whether the copy you have is still the copy they published - is still open.

Where Claude Code sits

Claude Code is conspicuously absent from the Technical Steering Committee, and its own plugin format predates and diverges from the new spec. Per Claude Code's plugin docs, a Claude Code plugin's manifest lives at .claude-plugin/plugin.json - nested inside a dot-prefixed directory - not at the plugin root the way Agent Plugins specifies. The Claude Code docs make no mention of Agent Plugins or agent-plugins.org. Both formats independently converge on a skills/<name>/SKILL.md layout, because both build on the same underlying Agent Skills spec, but a plugin.json written for one does not sit in the place the other expects it, and nothing in either spec bridges that gap automatically today. A plugin author targeting both ecosystems is packaging twice, or maintaining a translation step, not shipping one folder everywhere.

What this means for a manifest that already pins skills

skillfold's manifest currently resolves three kinds of sources - local paths, github: refs, and npm: packages - into SKILL.md-based skill directories, and its lockfile records a resolved commit SHA plus a sha256 integrity hash per skill (see docs/manifest.md). None of that reads or writes plugin.json, and skillfold has no concept of an MCP server declaration at all: mcp.json isn't a file type it looks for, parses, or installs. A skill packaged inside an Agent Plugins folder that skillfold happens to point at would only work if skills/<name>/SKILL.md inside it still resolves as a plain skill directory - the surrounding plugin.json and mcp.json would simply be ignored.

That's the honest limitation to state plainly: skillfold does not consume the Agent Plugins format, does not resolve mcp.json servers, and has no migration path for either as of this writing. If Agent Plugins gains real adoption and clients start expecting MCP servers to travel inside the same folder as skills, that's new surface skillfold's resolver doesn't cover yet. What the spec does confirm is the shape of the problem the ecosystem still hasn't agreed on: a portable package is not the same thing as a pinned, verifiable install, and five companies agreeing on the former just made that distinction easier to see.