Agent Plugins 1.0: one folder that every agent client can read

Agent Plugins 1.0.0 was published on 6 August 2026. It is a package format: one directory, one manifest, and optional skills and MCP servers inside it, so an extension written once can be loaded by more than one agent client. It is deliberately small, and the interesting parts are the constraints rather than the features.

The whole format, in one directory

The smallest useful plugin is three files:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

The manifest is minimal by design. Only two fields are required, $schema and name:

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

A client that supports skills reads plugin.json, discovers skills/greet/SKILL.md, and exposes it however it likes. How the skill is surfaced to a user or a model is explicitly outside the specification, which is the right call: that is where clients should differ.

The schema is closed, and that is the point

The manifest permits exactly ten top-level fields: $schema, name, version, description, author, homepage, repository, license, keywords and extensions. Anything else is unknown, and a client must report it, ignore it, and carry on loading. Clients must not assign meaning to fields the spec did not define.

This is the clause that decides whether the standard survives contact with five competing vendors. Without it, the first client to read a convenient extra key turns it into a de facto requirement, and portability erodes one field at a time. Client-specific data has a designated home instead: the extensions object, keyed by reverse-domain namespaces that each client owns.

The security model is containment, not permissions

This is the part most of the coverage skipped, and it is the part worth understanding before you package anything. The spec's safety property is that every path a client touches must resolve inside the plugin root. Symlinks may point to targets within the root; anything resolving outside must be rejected.

It then defines the failure boundary precisely, narrowest first. A plugin.json outside the root rejects the whole plugin. A component location outside it invalidates that component type. A stray SKILL.md is skipped individually. An MCP server whose command or cwd escapes containment invalidates that server entry. One bad path does not take down a plugin that is otherwise fine.

There is a deliberate hole in that, and it is documented: command arguments and environment variable values are opaque strings, and clients must not treat them as package paths. So containment covers the package, not what the package tells your machine to run. An MCP server entry is still a command executing on your computer with your privileges.

The specification defines a package format. It does not define installation, permissions, security policy, distribution, or trust. Those are still yours to solve.

That is not a criticism of the spec, which says so itself. It is a warning about how these things get read. "There is a standard now" is not the same as "this is safe now", and the gap between those two sentences is where supply-chain problems live. The same caution that applies to installing an MCP server applies here, with an extra layer of packaging in between you and the command.

Who is actually behind it

The Technical Steering Committee is five people: Clare Liguori (Amazon), Roshan Sadanani (Cursor), Harald Kirschner (Microsoft), Gav Verma (OpenAI) and Jonathan Hefner (Vercel), who is Lead Core Maintainer. The charter is unusually explicit that roles are held by individuals rather than organisations, that no seats are reserved for companies, and that no single vendor may hold a majority.

One absence is worth naming plainly, because it shapes how you should plan: Agent Skills originated at Anthropic, and Anthropic is not on the steering committee of the standard that packages them. Read that as a reason to check client support before you commit a distribution strategy to this format, not as a prediction about anyone's intentions.

Should you package your skills this way

• If you publish skills for other people: yes, the format costs almost nothing to adopt and the manifest is two required fields
• If your skills are internal to one client: not yet. You gain portability you are not using and a directory layer you now maintain
• If you ship MCP servers: bundle them, but do not treat the containment rule as a sandbox. It is not one
• Either way: version-pin the $schema value. It identifies the spec version, and 1.1.0 is already a working draft

Agent Plugins specificationThe normative spec, JSON schemas and governance charter.github.comAnthropic SkillsThe official skills repository, the largest source of SKILL.md examples to package.github.com

For the skills themselves rather than the wrapper, see the AI skills worth installing and the skills directory. For the MCP servers a plugin can bundle, the MCP directory.