Clarifying our external plugin policy

[aaronpowell]

The TL;DR

External plugins are restricted to repos from Microsoft/GitHub organisations and select Microsoft/GitHub partners. If you don't fall into those categories, you can still have a plugin listed in the Awesome Copilot plugin marketplace, it just needs to have all its items contributed directly to this repo first.

Longer explanation

When we merged #876 we added the ability to support external plugins. The primary goal was to enable teams within Microsoft to avoid having to create a plugin marketplace for every plugin they wished to ship. We only have a small collection of external plugins that we surface in the marketplace, at least at the time of writing. We have also started to work with some GitHub partners to surface them as well, but it's in a very selective manner.

The goal is to not have Awesome Copilot just be a generalised plugin marketplace but keep the ethos of being a well maintained and curated collection of Copilot customisations that are of inherent value to the community.

Why disallow general external plugins

We accept contributions of all forms to Awesome Copilot, whether you're a seasoned Copilot user with a finely honed set of agents and skills, or you're just getting started and have created something that optimises your workflow, so why do we disallow external plugins? Simply put - trust and transparency.

I'm going to describe this as how Copilot CLI works, but the pattern is the same on other Copilot experiences.

The way plugins work is that a repo provides a marketplace.json which is the directory for all the plugins that the marketplace makes available. The plugins listed in the marketplace can have a source property. If that is omitted, then the plugin is a "local" plugin, read from the metadata.pluginRoot property (or . by default). But the source property can also specify somewhere else to pull the plugin from, such as an external repo, hence the name "external plugins".

When you type /plugin install <some-external-plugin>@awesome-copilot here's what the CLI does:

• Checks for a cached version of the marketplace in ~/.copilot/marketplace-cache and either clones it if it doesn't exist or pulls to get updates
• Reads the marketplace.json
• Finds the plugin specified
• Looks for the source property (and we'll assume it exists for this explainer)
• If it's github then it will clone that GitHub repo using the repo property provided
• Read the plugin.json file from that repo
• Copy the agents/skills/etc. to the right places

This is a simplification of the process, but you should get the gist.

As you can see with this process, Awesome Copilot has very little involvement and as such, there is a lack of transparency as to what we're surfacing via the external plugin. Since we don't "see" the contents of the plugin we just trust that the author of it isn't doing anything malicious. Everything might have looked fine on the initial review, but since the source is just pointing to the default branch, that could drift without our knowledge.

Yes, you can specify a ref as part of the source to pin to a specific commit or tag, adding a level of immutability. But this doesn't scale as every update to the external plugin requires someone to submit a new PR to bump the ref, and there's no guarantee that anyone is reviewing what changed between refs. It shifts the problem from silent drift to manual tracking, neither of which gives us the confidence we need.

What we have in place for local plugins

When a plugin's contents live directly in this repo, they go through a pipeline that gives us, and you, a much higher level of confidence:

• PR review: Every change to an agent, skill, or instruction goes through a pull request. Maintainers and the community can review exactly what's being added or changed before it's merged.
• Automated validation: We run validation checks (collection validation, skill validation, front matter checks) as part of the contribution workflow. These catch structural issues, naming violations, and missing metadata before anything lands on main.
• Deterministic plugin generation: Plugins aren't manually assembled. They're auto-generated from plugin.json files using some conventions on how to package them. This means the plugin you install is a direct, verifiable reflection of the reviewed content in the repo. There are no hidden differences.
• Single source of truth: Because plugins reference source files are copied from their folder in the repo, there's no way for a plugin's contents to silently diverge from what was reviewed. What you see in the repo is what you get.

External plugins bypass all of this. There's no PR review, no validation, no deterministic generation — just a pointer to someone else's repo.

So what should you do?

If you want your plugin available in the Awesome Copilot marketplace, contribute your agents, skills, and instructions directly to this repo. Create the plugin,json and a plugin will be generated when merged to main. See CONTRIBUTING.md for the full guide on how to do this.

This is the kind of problem that is experienced by all marketplaces, whether it's npm, pypi, VS Code marketplace, etc. and we want to ensure that you can trust what you are bringing into your agentic workflows from Awesome Copilot.