Agent Plugins 1.0 — a packaging standard built on Agent Skills, without Anthropic

Why you'd careThe problem it solves

You wrote one skill. It is a folder with a SKILL.md in it and it is genuinely portable, because the skill format is the same everywhere it is implemented. What is not portable is everything wrapped around that folder: the manifest that names it, the file that declares which MCP server it needs, the directory layout each client expects to find it in. So the skill travels and the package does not, and shipping the same behaviour to four editors means four packaging jobs and four things to keep in step.

Agent Plugins 1.0 is a specification for exactly that wrapper, and reading its scope is the fastest way to understand what it will and will not do for you. It standardises the box. It leaves what happens to the box — install, update, trust, registries — to whoever opens it.

ConceptWhat it is

Agent Plugins 1.0.0 was released on 2026-08-06. A plugin under the specification is a directory with four possible parts, only one of which is required:

• plugin.jsonrequired. The root manifest: the schema it conforms to, the plugin's name, and its metadata.
• skills/optional. Each immediate subdirectory becomes an Agent Skill through its SKILL.md, in the format that already exists.
• mcp.jsonoptional. MCP server configuration.
• Client namespaces — optional. Reverse-domain directories holding extensions specific to one client.

The specification is explicit about why it stops where it does, in a sentence worth quoting rather than paraphrasing: “Agent Plugins v1 focuses on Agent Skills and MCP because both have established specifications outside this project and meaningful cross-client adoption.” The launch post adds that “Agent Plugins does not attempt to redefine them.” The Agent Skills specification remains the authority for the skill format, and MCP remains the tool-connection protocol. Two things it builds on that it did not author: the Agent Skills specification, originally created by Anthropic in 2025, and MCP, now stewarded by the Linux Foundation's Agentic AI Foundation.

Governance is part of the description because it is part of what makes a packaging format worth adopting. Vercel initiated the proposal and refined it with AWS, Anysphere, GitHub, Microsoft and OpenAI. The initial technical steering committee is Amazon, Cursor, Microsoft, OpenAI and Vercel, and Google announced on launch day that it is joining as a core maintainer, though the specification repository's MAINTAINERS.md still lists only the five founding members. Anthropic does not appear among the steering committee, the collaborators or the maintainers, and Claude Code keeps its own plugin format outside this standard. For a skill author that is a routing fact rather than a verdict: the format your SKILL.md is written in is the same either way, and the packaging around it is what differs per destination.

How it worksThe mechanics

The whole specification is a directory shape, which is the point of it:

my-plugin/
  plugin.json          required - schema, name, metadata
  skills/
    changelog/
      SKILL.md         an ordinary Agent Skill, unchanged
    incident-review/
      SKILL.md
  mcp.json             optional - MCP server configuration
  com.example.client/  optional - one client's own extensions

The immediate subdirectories of skills/ are the skills. Nothing about the SKILL.md inside them is new, and nothing needs rewriting to be packaged this way — a skill you already have becomes a plugin by acquiring a manifest above it.

Two scope statements decide what you can actually rely on. The first comes from the project's guide for client implementers, which says Agent Plugins “does not prescribe” “installation sources, registries, or marketplaces”, “enablement, update, or cache user experience” or “permission prompts, trust policy, or sandboxing”. So a plugin that conforms to 1.0 is a package two clients can both read; how each of them fetches it, decides whether to trust it, and updates it later is unspecified and will differ. The second, from the specification: other proposed component types, “such as commands, hooks, agents, rules, and LSP servers”, are “outside the v1 format until their formats converge.” Clients keep those inside their own extension namespaces, which is what the reverse-domain directories are for.

The practical consequence for authoring is a split you can plan around. Put the behaviour in skills/ and the tool connections in mcp.json, and both travel. Put anything that depends on one client's command syntax, hook points or subagent model into that client's namespace directory, and expect it to travel nowhere — not as a defect, but as the declared boundary of v1.

The format was reported at launch as already integrated into VS Code, Copilot, Cursor, ChatGPT and Kiro. Treat any specific client as needing a check on the day you depend on it: implementation status is exactly the kind of fact that moves between the announcement and your build.

At a glanceSee it

What the package format standardises, and the layer it deliberately leaves to each client.

Where it runsSurfaces and availability

The reason to know all of this while writing one skill is that it changes where you put things, not whether you write them. Anything in skills/ is behaviour you author once and package for several destinations. Anything that leans on a client's command syntax, hook points or subagent model is per-client work, and v1 says so rather than leaving you to discover it. And because the whole supply chain — who may install, from where, with what permissions, updated how — sits outside the specification, a package that conforms tells you the shape of the box and nothing about its provenance. That question stays where it was: with the client, and with whoever operates it.

ExampleIn the real world

A team maintains a skill that encodes their API's pagination and error conventions, so that generated client code stops getting retries wrong. It is one SKILL.md and two reference files, and it is already used daily in one editor.

Two other teams use different editors, and both ask for it. Under Agent Plugins the packaging job is small and, importantly, done once: a plugin.json at the root, the existing skill folder moved under skills/api-conventions/ untouched, and an mcp.json declaring the internal schema server the skill tells the model to consult. Nothing inside the SKILL.md changes.

What the team still has to decide is everything the specification declined to decide for them. Where does the package live and how does a colleague get it — a URL, an internal registry, a checkout? What is a plugin permitted to do once installed? How does a fix reach the three teams next month? Each of the three clients answers those differently, so the answer is three short internal notes rather than one.

They also had a slash command wrapping the skill for convenience. That does not come along: commands are not a portable component type in v1. It goes into the client namespace directory for the editor that supports it, and the other two teams invoke the skill by asking for it, which is how it worked in the first place.

Not thisWhat it is often confused with

• Not a new skill formatthe specification defers to the Agent Skills specification, and the launch post says Agent Plugins “does not attempt to redefine” it. The SKILL.md under skills/<name>/ is the Agent Skills format you already write.
• Not a replacement for MCPthe same launch-post sentence covers MCP. mcp.json declares servers; the protocol is unchanged and the plugin does not sit in the wire path.
• Not a registryregistries are explicitly out of scope. There is no index, no canonical location and no naming authority in the specification.
• Not a permission or trust modelpermission prompts and trust policy are named among what the format does not prescribe. Conformance says a client can read the package, not that opening it is safe.
• Not Claude Code's plugin formatthat is a separate format outside this standard. The two use overlapping vocabulary and are not interchangeable.
• Not a home for commands, hooks or custom agentsthose are not portable component types in v1 and live in client namespaces.

LimitsWhen not to reach for it

• You ship to exactly one client.Its native format is fewer moving parts and gets you the features v1 leaves out. Portability you do not use is overhead you do pay.
• The value is in commands, hooks or a custom agent.None of those are portable component types in v1, so packaging them this way moves nothing across a client boundary.
• You needed the supply chain solved.Install, updates, permissions and registries are things the format declares it does not prescribe. If your requirement is signed provenance or a controlled rollout, that requirement is unmet here and has to be met somewhere else.
• Your target has not implemented it.The integration list came from launch reporting. Verify the client you care about before designing a distribution plan around conformance.
• The skill is a private one-off.A folder in the project is still the cheapest thing that works, and the packaging layer only starts paying once something has to leave the project.

RelatedGo deeper