Conformance Lets a Client Ignore Half Your Plugin

GitHub made Agent Plugins 1.0 generally available on 12 August in VS Code, Copilot CLI, the GitHub Copilot SDK and the GitHub Copilot app, on all Copilot plans, with the Awesome Copilot marketplace wired in as the default install source in three of them. The pitch is portability: package your agent skills and MCP servers once, install them in anything that conforms.

The specification lives in its own repository, separate from the announcement, and it is the thing worth reading. It is direct about what it does not do.

What it standardizes

Two component types, and only two. Skills live in a skills/ directory, one subdirectory each, discovered by the presence of a SKILL.md that conforms to the external Agent Skills specification. MCP servers are configured in an mcp.json at the plugin root, over stdio or streamable-http; the older HTTP-plus-SSE transport is deprecated and optional. A root plugin.json manifest is mandatory and requires exactly two fields — a $schema URL and a name. Version, description, author, license, repository and keywords are all optional.

The hand-rolling it saves you is real. Shipping one capability bundle to a team running several different agent clients used to mean a packaging convention and an install path per client.

The conformance rule the announcement did not mention

A client must support at least one component type. Not both.

The spec states that a client implementing only skills conforms. It also says missing component locations do not trigger errors, and invalid entries skip gracefully without affecting other components. Both are correct choices for a package format. Together they bound the portability claim: a plugin carrying a skill and an MCP server installs cleanly into a conforming skills-only client, which discovers the skill and never reads mcp.json. Nothing fails. Nothing warns you. Install-anywhere is guaranteed; behaves-the-same is not.

That is a package format, not a runtime contract — the same gap that swallows integration work everywhere else in this stack, and the subject of why enterprise AI doesn't ship.

What 1.0.0 explicitly is not

Plugin discovery, downloading, installation, trust models, permission systems and sandboxing are all named as out of scope for v1 and left client-defined. The repository keeps a separate FUTURE_CONSIDERATIONS document, marked non-normative, listing what that leaves open: permission and approval UX, provenance verification, secret handling, enterprise controls such as allowlists and organization-scoped registries, audit-trail event schemas, dependency resolution between plugins, and a conformance test suite.

What v1 does say about safety is narrow, and worth knowing precisely. Clients must reject package paths that resolve outside the plugin root, and symlinks must not be used to escape the package — but that containment rule governs plugin-supplied files, not subprocess sandboxing. When launching an MCP server, a client may inherit the ambient environment or may sanitize it; both conform. The spec says outright that configured env values are visible package data rather than a portable secret mechanism, and warns against embedding credentials in them.

So the enforcement you get is whatever your client implements. GitHub's answer is managed-settings.json for Copilot Business and Enterprise — a GitHub control, not a standard one. The project's own tracker records the gap: issue 55, opened on 12 August, the same day GA landed, asks how a future revision could declare remote MCP authentication requirements without carrying credentials.

Maturity, from the activity rather than the prose

The repository has 79 commits on main, 964 stars, 57 forks, 24 watchers, 11 open issues and 3 open pull requests.

It has no tags and no releases. Version 1.0.0 is a directory name — spec/1.0.0.md and schemas/1.0.0/ — and a URL under agent-plugins.org. There is no git ref to pin, so being on 1.0.0 means being on whatever main said when you last looked.

The visible commit history runs from 16 July to 6 August, with older commits behind pagination. In that window the project was renamed to Agent Plugins, published the 1.0.0 specification on 24 July, dropped its DCO sign-off requirement the same day, recorded its Lead Core Maintainer selection on 27 July, and changed its self-description to an open standard on 6 August.

Governance is further along than the specification. There is a technical charter, a steering committee of five core maintainers who hold their seats as individuals rather than as companies — Clare Liguori of Amazon, Roshan Sadanani of Cursor, Harald Kirschner of Microsoft, Gav Verma of OpenAI, and Jonathan Hefner of Vercel as Lead Core Maintainer and tiebreaker — and a charter rule that no single vendor may hold a majority of seats. Licensing is split: CC-BY-4.0 for the specification text and documentation, Apache-2.0 for the schemas and code.

The issue tracker is where the seams show. The oldest open issue asks the way forward for the project and dates to 11 May. Issue 40, opened 6 August, records that there is no portable way for a plugin's MCP server to learn the user's workspace root.

Who should not use it

Anyone who needs signed provenance, a declared permission surface or standardized audit events this quarter. Those are listed as future work, not gaps you can configure around.

Everyone else can adopt it, with six things written down:

• Pin plugins by commit SHA. There is no tag to pin.
• Inventory your clients, not your plugins: for each client in the fleet, record whether it implements skills, MCP servers, or both.
• Review mcp.json as a supply-chain artifact. Every stdio entry is a subprocess on a developer machine, and no clause requires your client to sanitize its environment first.
• Grep each plugin for credentials in env before install, because the spec classifies those values as visible package data.
• If you want a declared tool surface today, the only one in the stack is the optional allowed-tools field in SKILL.md — marked experimental, with support varying between implementations.
• Enforce with what your client actually gives you. On Copilot Business and Enterprise that is managed-settings.json.

The claim here is falsifiable and the repository holds the falsifier. If a normative permission model and a conformance test suite move out of FUTURE_CONSIDERATIONS and into the specification, then conformance starts to mean behavioral equivalence and this post is wrong. Until both land, a conforming client is one that can read your package — not one that will run it the way the client next to it does. That is a distribution win worth taking, and an evaluation problem you still own, which is the argument in from PoC to production AI applied to packaging.