Agent Plugins 1.0 Means You Package Your Skills Once Instead of Five Times. That Is a Bigger Deal for a One-Person Shop Than for Microsoft.
Agent Plugins 1.0 launched on August 6, 2026, with VS Code among the clients supporting it at launch. A conforming plugin is a directory containing a plugin.json manifest, skills in skills/, and MCP server configuration in mcp.json. That is the entire shape.
It is the least exciting announcement I have written about this month and probably the one that saves me the most time.
The tax was never writing the skill
Here is the thing that has quietly made publishing agent extensions unattractive: writing the skill is the easy part. A useful skill is a markdown file and maybe a script. I can write one in an afternoon.
What I could not do in an afternoon was ship it to more than one place. Every agent client expected its own directory layout, its own manifest format, its own idea of where an MCP server config belongs. Publishing the same skill and MCP server to several tools meant maintaining a separate package for each, which means separate release processes, separate docs, separate bug reports from users who are on the client you deprioritized.
So the rational move for a solo operator was to pick one client and ignore the rest. Which is exactly the outcome that keeps the ecosystem small, and exactly the outcome a shared manifest fixes.
Boring is the feature
Look at the spec shape again: a manifest, a skills/ directory, an mcp.json. There is nothing clever in there. No new package format, no registry requirement in the core, no build step.
I think that is deliberate and correct. The failure mode for standards like this is ambition. Something tries to specify capability negotiation and sandboxing and permission models on day one, everybody implements a different 60% of it, and three years later you have five incompatible dialects of one standard, which is strictly worse than five honest incompatible formats because now everyone believes portability exists.
A directory with three known locations in it is a thing you can implement in an afternoon and be wrong about in very few ways. That is the property you want.
The vendor-specific escape hatch is namespaced rather than banned, which is the other design decision I would call correct. VS Code reads the portable components and also reads Copilot-specific components from a com.github.copilot namespace inside the same package. So one directory carries the portable core plus whatever any given client needs on top, and clients that do not know a namespace ignore it.
Where these things usually break
I have watched enough of these to know where the fracture line runs, and it is the namespace.
The pattern is predictable. The portable core covers 80% of what you want. The remaining 20% is where the actual product differentiation lives, so every vendor pushes their good features into their own namespace. Over a couple of years the namespaced section grows until the portable core is a lowest-common-denominator stub and you are back to maintaining five packages, except now they share a filename.
The tell to watch for is whether a client can do something useful using only the portable components, or whether the portable part is a shim that requires the namespace to do real work. Right now, on the VS Code side, portable skills and MCP servers appear to be genuinely functional and the Copilot namespace is additive. If in six months the interesting capabilities have migrated into namespaces, the standard has failed regardless of how many logos are on the launch page.
The second thing I would watch is whether the standard develops a real conformance test. Without one, "supports Agent Plugins 1.0" means whatever each vendor's marketing decides it means, and the first time you discover a client's interpretation differs from yours is when a user files a bug.
What I'd actually do
Do not migrate anything yet. Do write new plugins in the standard's shape.
The distinction matters. If you have an existing skill that works in one client and has users, moving it buys you nothing today, because the portability only pays off once you actually want a second client, and it costs you a release cycle plus whatever breaks. Migration is a bet on adoption that has not resolved.
But the layout is free for anything new. A plugin.json, a skills/ directory, an mcp.json. Even if the standard goes nowhere, you have lost nothing, because that is a reasonable way to organize a plugin regardless of what reads it. That asymmetry (free to adopt for new work, costly to retrofit) is why I would not spend a day converting a back catalog on an announcement that is sixteen days old.
The trigger for actually migrating, for me, is a second client I care about shipping real support. Not announcing it. Shipping it, and me having a user who asks for it. Until then, adopting the layout for new work keeps the option open at zero cost, which is the whole point of an option.
One practical note: keep your skill content free of client-specific assumptions even inside the portable section. The number of skills I have seen that hardcode a particular client's tool names or prompt conventions is high, and a shared manifest does not fix that. The manifest makes the package portable; it does not make your prose portable.
Where I could be wrong
The strongest counter is that I am underrating the value of being early. If Agent Plugins does become the default, the plugins that were there on day one accumulate installs and reviews and end up as the reference implementation everyone copies. "Wait for adoption" is how you show up to a standard eighteen months late with a technically superior package that nobody finds. That is a real cost and my recommendation ignores it.
I should also be honest about the limits of what I actually verified here. I am working from the VS Code 1.133 release notes and the standard's own site, on a spec that is sixteen days old. I have not built a plugin against it, I do not know how many clients have shipped working support versus announced intent, and "VS Code was part of its launch along with other agent clients" is as specific as the release notes get about who else is in. If the answer to "who else actually implements this" turns out to be nobody, then this post is about a Microsoft directory convention with an open-standard label on it, and the advice to write new work in that shape is still fine but the reasoning behind it is wrong.
Author
Lukas
@lukcombinator