GitHub Copilot's Agent Plugins Standard Packages a Skill Once for Every Client. Six Vendors Signed On.

If you build a custom skill or tool integration for GitHub Copilot, you likely already know the annoying part: you don’t just write it once. You write it, then repackage it for every client that runs it, because each one wants its own file layout.

That’s the problem GitHub says Agent Plugins 1.0 fixes. The open standard, published August 6, is now generally available in VS Code, GitHub Copilot CLI (the version you run by typing commands instead of clicking through an editor), the Copilot SDK (the toolkit other developers use to build their own products on top of Copilot), and the Copilot app, on every Copilot plan.

What actually changed

An agent plugin bundles two things builders use to extend a coding agent: a skill (written instructions that teach the agent how to handle a specific task, like following your team’s pull request template) and an MCP server (a small program that lets the agent call an outside tool or data source, like a ticket tracker or a database, through a standard connection instead of custom code for each integration).

Before Agent Plugins 1.0, the skill and the MCP server underneath were the same no matter which client ran them. The packaging around them wasn’t. You maintained a separate manifest (a file that lists what’s in the package and how to load it) and folder layout for VS Code versus the CLI versus any other client, even though nothing about the actual behavior changed. Agent Plugins 1.0 replaces that with one package format that any compatible client can read.

It’s not just a GitHub project

The more notable part of this release is who signed on to maintain the spec alongside GitHub: AWS, Anysphere (the company that builds Cursor), Microsoft, OpenAI, and Vercel at launch, with Google joining as a core maintainer the same day.

That’s six of the biggest names in AI coding tools agreeing on one packaging format instead of each pushing its own. It’s a real signal that these vendors want plugins to move between tools, not lock builders into one client’s ecosystem.

One important caveat: the general availability GitHub announced applies to GitHub’s own Copilot surfaces, VS Code, Copilot CLI, the Copilot SDK, and the Copilot app. GitHub’s changelog post doesn’t say the other maintainers have shipped Agent Plugins support in their own products yet, so treat cross-tool portability as a direction this group has committed to, not something you can rely on in Cursor or another maintainer’s tool today.

What you can do with it right now

Inside VS Code, Copilot CLI, or the Copilot app, you can browse the Awesome Copilot marketplace, which ships by default in all three, and install any plugin built to the new spec. If you already maintain custom Copilot plugins that don’t target Agent Plugins 1.0, GitHub says they keep working with no forced migration.

If you’re the one who maintains a plugin for your team, adopting the spec is mostly a manifest update rather than a rewrite: add a $schema field to your plugin.json file (a technical marker that tells the client which version of the packaging format the plugin follows), keep your skill files under a skills/ folder and your MCP configuration in mcp.json as before, and move any Copilot-only files into a com.github.copilot/ folder that other clients simply ignore.

The part worth checking before you install anything

An agent plugin isn’t just documentation. It can bundle an MCP server, which is real code that gets access to whatever tools and data you connect it to, potentially including your repository (the codebase and history for the project you’re working in). Installing an unfamiliar plugin from a marketplace grants that access without you personally reviewing what the server does.

Before installing a plugin you don’t already trust, check who published it and where its source lives in the marketplace listing. If you administer Copilot for a team, GitHub’s write-up says admins can restrict which plugins are allowed at all through a managed-settings.json configuration file, using an enabledPlugins list to name approved plugins and a strictKnownMarketplaces setting to block installs from anywhere outside approved marketplaces. Admins can also allowlist or block individual MCP servers by name, command, or URL.

This isn’t a new risk Agent Plugins introduced. It’s the same MCP access question we flagged two weeks ago when GitHub Copilot code review added skills and MCP support: read-only access to an MCP server can still surface context you didn’t intend to share. Agent Plugins 1.0 makes installing that access easier, which makes checking the source before you do it more important, not less.

What builders should do next

Open the Awesome Copilot marketplace inside VS Code or Copilot CLI and look for a skill or MCP server you already use as a one-off setup. If it now ships as a single Agent Plugins package, installing that version means you won’t have to reconfigure it separately the next time you switch between VS Code, the CLI, and the Copilot app.

If you maintain a plugin for your team, the update is small: add $schema to plugin.json, keep your skills/ folder and mcp.json where they are, and move anything Copilot-specific into com.github.copilot/. Test it by installing the updated plugin in two different clients, like VS Code and Copilot CLI, and confirming the skill behaves the same way in both without any client-specific setup.

Where this goes next

Six vendors agreeing on a packaging format instead of competing on lock-in is unusual in this market, and worth watching. But the real test isn’t the announcement, it’s whether a plugin built today actually shows up working inside Cursor, an AWS tool, or another maintainer’s product without GitHub in the loop. Nothing published so far confirms that’s happened yet.

End of article