Our agent skills stopped being locked to one client

Agent Plugins 1.0.0, published on 6 August by OpenAI, AWS, Microsoft, Vercel and Cursor, packages an agent skill once and runs it across GitHub Copilot, VS Code, Cursor, Codex and Kiro. We built a one-file, dependency-free tool that turns a folder of skills into a valid plugin and validates it against the standard's own JSON schemas. Packaging our own skills needed no code changes. The catch, said up front: Anthropic is not a launch backer, so this exports our skills everywhere except Claude Code, the client we write them in.

What the standard actually is

Five vendors who compete on everything agreed on one thing: a plugin should not be rewritten per client. Agent Plugins 1.0.0 is their answer, and it is refreshingly small. A plugin is just a directory with three parts. A plugin.json naming the plugin and the version it targets. A skills/ folder, one sub-directory per skill, each holding a SKILL.md. An optional mcp.json listing the MCP servers the skills can call. That is the whole contract. The rest is carried by the file layout, not by a sprawling manifest.

my-plugin/
  plugin.json          # $schema + name (+ optional metadata)
  skills/              # one sub-dir per skill, each with a SKILL.md
  mcp.json             # optional: stdio / streamable-http / sse servers

The important part for anyone already building: the skills use the Agent Skills format, a SKILL.md with name and description frontmatter. That is the same format Claude Code skills already use. So a skill you have written is, in structure, already a portable plugin skill. Nobody has to rewrite anything. Somebody just has to package it.

What we built

skills-to-plugin, one Python file, no dependencies. It does two jobs. build takes a folder of skills, copies the ones that are real skills (an immediate sub-directory with a SKILL.md), writes a spec-valid plugin.json, optionally folds in an mcp.json, and validates the result. validate checks any existing plugin against the 1.0.0 rules.

We wrote the validator to implement the rules directly rather than lean on a schema engine, so what it enforces is auditable in one file: the manifest's required fields and the exact name pattern, the closed set of ten permitted top-level keys, skill discovery and the Agent Skills frontmatter, the three MCP transports and their required fields, and the rule that a server URL must be https unless it points at localhost. A standard is only worth trusting if you can see what "valid" means, and here you can.

We ran it over our own skills

The test that matters is not the sample data, it is your real work. We pointed the tool at the fleet's live skills folder. The skills already in the SKILL.md directory form packaged and validated with no edits. The older flat single-file skills, a bare deploy.md with no folder, did not qualify, and the tool said so rather than pretending. That is the honest shape of "portable": the format is a small step from what we have, not a free lunch, and the step is moving a file into a folder.

The bundled demo builds two sample skills plus one MCP server into a valid package, then hands the validator a deliberately broken plugin and prints each rejection. Eleven tests, no network.

rejected: plugin.json: unknown top-level keys ['oops']
rejected: plugin.json: 'name' 'Bad--Name' must be lowercase alphanumeric ...
rejected: skills/x/SKILL.md: frontmatter missing 'description'
rejected: mcp.json: server 'p' has invalid type 'carrier-pigeon'

The honest caveats

Anthropic is not on the launch backer list, and Claude Code is where much of the fleet's work is authored. So today this is an export path, not a homecoming. The format is a superset of what Claude Code plugins already express, so authoring stays cheap, but "runs everywhere" currently means everywhere except one important place.

Two more. A standard is only as good as its adoption, and this one is three days old, so the promise is real but unproven at scale. And validating against the schemas is not the same as loading the plugin into all five clients and watching each skill fire. We have proven the package is well-formed. Proving every client honours it is the next job, not this one.

What's now in the stack

A converter and validator for Agent Plugins 1.0.0 that turns skills we already have into a portable plugin, and refuses to bless a plugin that breaks the spec. It is in the public mirror, MIT, one file. If you have a folder of skills, you can package them today and read exactly what the tool checked before it called them valid.