GitHub Copilot Plugins for Enterprise AI Governance: Versioned Skills, MCP and Agent Plugins 1.0

The post is a case study. Microsoft engineers describe building a migration and modernization toolkit with a large enterprise customer whose internal and third-party teams were modernizing thousands of applications. They packaged the customer's architecture guidance, agent instructions and tool connections as versioned Copilot plugins. Application-specific context and decisions stayed in each application's repository. This article covers what they built, how the plumbing works today, and where the approach has limits.

Why "just copy the files" stops working​

The authors' starting point will sound familiar to anyone who has run a platform team. Sharing agent files once is easy. Keeping every consumer supplied with fixes, updated guidance and compatible tool configurations is the hard part. If each application repository gets its own copy, each team then has to merge every upstream change with its own local edits, and that doesn't scale past a handful of teams.

The team picked Copilot's built-in plugin support rather than writing its own packaging and loading mechanism, so they could spend their time on content and release practices. GitHub describes a plugin as a distributable package that extends Copilot's functionality, bundled into a single installable unit. According to GitHub's documentation, a plugin can carry custom agents, skills, hooks, MCP server configurations and LSP server configurations.

The customer's engineers mostly used VS Code and GitHub Copilot CLI, and both support plugins, so the toolkit could go into tools people already had open.

Section summary: The problem was keeping many teams in sync over time, not getting files to them once. Plugins supply the versioned, installable package that copy-and-paste lacks.

The timing: Agent Plugins 1.0 is now a shared format​

This case study lands shortly after a relevant platform change. On August 12, 2026, GitHub's changelog announced Agent Plugins 1.0 support that is generally available in VS Code, Copilot CLI, the GitHub Copilot SDK, and the GitHub Copilot app, on all Copilot plans. The changelog also describes what that fixes. Before, while the skill and the server underneath were the same for every client, the packaging around them wasn't, so you maintained a separate manifest and directory layout for each one.

The portability has limits, and the Microsoft post is careful to state them. Microsoft's VS Code documentation says Agent Plugins 1.0 defines skills and MCP servers as portable component types. Other capabilities are client-specific and use the standard's reverse-domain client extension namespaces. Custom agents, hooks, commands and LSP configurations sit in a com.github.copilot directory, which other clients ignore.

Existing investments are protected. GitHub states that existing GitHub Copilot plugins that don't target Agent Plugins 1.0 remain supported, with no migration required. For new work, GitHub's guidance is simple: for a new plugin, use Agent Plugins 1.0 unless you require configurable component paths.

Section summary: Skills and MCP configurations can move between compatible clients. Agents and hooks remain Copilot-specific. If you're writing a new plugin, use the 1.0 format.

What went in the box, and what stayed out​

The most useful part of the post is where it draws the line on content. The shared package held the customer's migration constraints, agent instructions and tool connections. Evidence and decisions about individual applications stayed with the teams that own those applications.

The authors use migration planning as the example:

• From the plugin: the planning agent's instructions, a migration-context skill containing the program's constraints and terminology, and MCP configuration for the tools the workflow uses.
• From the application repository: source code, existing documentation and service-specific decisions.
• Where the output goes: the finished migration plan stays in the application repository, where the team can review and change it alongside the code.
• Where access comes from: credentials come from the consumer's own environment. Shipping a tool connection's configuration does not give anyone access to the system behind it.

That last point deserves attention from security teams. A plugin can describe how to reach a system, but it doesn't grant permission to use it. Resources maintained elsewhere stay where they are. In the case study, approved architecture templates kept their own repositories and release history, and the skill pointed to them rather than duplicating them.

The trade-off is that installing the plugin gives a team the reusable workflow and nothing more. They still need their application context, access to the referenced resources and authorized tool access before it's useful.

Section summary: Share the workflow. Keep evidence, decisions, outputs and credentials with the people who own them.

How distribution actually works​

No separate hosting service was needed. The team kept the toolkit in an internal GitHub repository, used a fork of the open-source devsquad-copilot framework as its base, and maintained it with the same pull request and release practices as any other code.

Two manifests do the work:

1. plugin.json describes an individual package.
2. marketplace.json is a catalog listing the sources and metadata of available packages. GitHub's docs say the marketplace.json file is the only required component of a plugin marketplace. Adding it to a repository allows Copilot CLI to recognize the repository as a plugin marketplace. The file goes in the .github/plugin directory.

For Copilot CLI users, GitHub's documentation lists these commands:

• Register an internal marketplace: copilot plugin marketplace add OWNER/REPO (or a local path, or a non-GitHub Git URL)
• Install a package: copilot plugin install PLUGIN-NAME@MARKETPLACE-NAME
• Manage it: copilot plugin list, copilot plugin update PLUGIN-NAME, copilot plugin disable/enable, and copilot plugin uninstall

In VS Code, you can install a plugin directly from a Git repository URL without adding a full marketplace first. Run Chat: Install Plugin From Source from the Command Palette. The two clients also work together: VS Code automatically discovers plugins that you install with the GitHub Copilot CLI to enable you to use them also in VS Code.

One governance detail is easy to miss. Plugins can be installed straight from a repository, so leaving a plugin out of the marketplace only hides it from the catalog. It doesn't restrict repository access or block other ways of installing it. Access control belongs to repository permissions.

Versioning, updates, and the "which version are you on?" question​

The authors wanted identifiable releases for an unglamorous reason: bug reports. If an engineer includes their installed plugin version in a report, maintainers can pull up the matching instructions and configuration without needing central visibility into every installation. Versioned releases also let maintainers test updates before wider rollout and plan a return to a known-good version. The authors add that rollback only works if old releases are retained and the recovery procedure has been tested for the client and installation source in use.

The post is also clear that publishing a release doesn't mean everyone has it. One team may install a revised planning agent while another stays on the old one. Update behavior depends on client settings and package source. In VS Code, according to Microsoft's docs, updates are checked when you run Extensions: Check for Extension Updates, or every 24 hours if extensions.autoUpdate is on. Plugins sourced from npm or PyPI never update automatically and need an explicit Update click.

Enterprises now have a lever the post doesn't cover. According to GitHub's changelog, Copilot Business and Enterprise customers can use existing enterprise managed settings across VS Code, Copilot CLI, the GitHub Copilot app, and Copilot cloud agent. Within managed-settings.json, admins can use enabledPlugins to automatically install or block specific plugins, extraKnownMarketplaces to add marketplaces available to developers, and strictKnownMarketplaces to restrict installation to managed marketplaces. Organizations that want a guaranteed baseline, rather than relying on each engineer to install things, should look here.

Section summary: Versions make troubleshooting possible, but they don't make everyone consistent. Managed settings are the enterprise tool for closing that gap.

The components doing the real work​

The toolkit was built around recurring migration tasks:

• Spec-driven templates. A migration specification template covering the current system, the target, dependencies, test scenarios, success criteria and rollback expectations, plus an architecture decision record template. The templates ship with the plugin. The finished documents live with the application code.
• Code navigation. A session-start hook checked for user-level or project-level LSP configuration, and a companion skill walked engineers through language-server setup. The authors say configuration alone doesn't prove navigation works, so engineers still had to confirm it in their client.
• Java modernization. Agents connected over MCP to the GitHub Copilot App Modernization MCP Server for repository assessment, upgrade planning, builds, tests, dependency vulnerability checks and migration consistency checks. Microsoft Learn's quickstart for the modernization tooling describes a validation loop that includes CVE detection, build fixes, consistency validation and test runs.
• Azure inputs. Azure MCP supplied deployment guidance, pricing, Bicep schemas, Terraform practices and policy and access-control inspection. Microsoft Learn MCP provided official documentation and code samples. Microsoft's Azure MCP Terraform reference says those tools can validate Terraform workspaces and plans against the Azure policy library via conftest. Treat that as an input to architectural judgment, not a replacement for it.

Governance lessons worth stealing​

• Give shared agents and skills distinctive names. In Copilot CLI, a project-level agent with the same identifier can take precedence over the packaged one. An engineer could install your update and keep running their local instructions without knowing it. MCP server configurations follow different loading rules and need separate review.
• Declare explicit tool lists per agent. Reviewers can see what each role can touch, and adding a new integration won't quietly widen an agent's capabilities.
• Don't pin models in the package. Leave model choice to users or administrators within enterprise policy, so trying a new model doesn't require a toolkit release.
• Run it like a product. The toolkit had a roadmap, a backlog, releases and an inner-source contribution path, so internal and third-party engineers could propose improvements for architecture owners to review.
• Review before you install. Microsoft's VS Code docs warn that plugins can include hooks and MCP servers that run code on your machine, and advise checking contents and publishers first.

The reality check​

This is a design pattern described by the people who built it. It isn't a benchmark. The post gives no adoption figures, productivity measurements or before-and-after comparison, so the "consistent" in the title is a goal, not a measured result. Consistency can still slip through different installed versions, client-specific component support, local overrides, missing permissions and missing application context. The authors acknowledge most of these points themselves.

The underlying argument holds up, though. Prompt files and MCP configs are now infrastructure, and infrastructure copied around by hand drifts. The authors recommend starting small: pick one workflow where teams keep assembling the same instructions and tool connections, package only the shared parts, give it an owner and a release process, and let feedback from other teams decide what gets packaged next.