GitHub Copilot plugins turn agent workflows into packages

Microsoft's developer division has explained how it packaged an application migration and modernisation toolkit for a large enterprise customer as a GitHub Copilot plugin, turning a folder of agent instructions, skills and tool configuration into something a team can install, version and roll back. The write-up, published on 29 September, is a worked example of platform engineering applied to AI-assisted development: shared capability travels as a release, while application-specific decisions stay in the repository that owns them.

Why copying files stops working

Sharing agent artefacts works until the second team copies them. After that, every reworded instruction, every fix and every changed tool connection has to be reconciled by hand in each repository, and it stops being possible to say which version a colleague is actually running. Microsoft describes the same problem from the maintainer's side: distributing the files is easy, keeping the people who adopted them supplied with fixes and compatible configuration is not.

The answer the team settled on was an installable, versioned package rather than a shared folder. Microsoft says using Copilot's existing plugin support meant it did not have to build and maintain its own packaging and loading mechanism, and that support for the open Agent Plugins specification offers a route to reusing skills and MCP configuration across compatible clients.

What travels inside the package

The toolkit carries the programme's migration constraints, the planning agent's instructions, a migration-context skill and the MCP configuration for the tools the workflow depends on. The application repository supplies the other half of the picture: its source code, its existing documentation, its service-specific decisions and the migration plan the engineer produces, which stays with the application so the team can review it alongside the code.

Credentials stay where they belong. Shipping the configuration for a tool connection does not hand over access to the system behind it, because authorisation still comes from the consumer's own environment. Microsoft makes the same distinction for approved architecture templates, which keep their own repositories and release history, with the skill pointing at their source rather than absorbing them.

Two limits are worth noting. Custom agents and hooks depend on client-specific support rather than the shared specification, and packaging is deliberately separate from catalogue publication, so a plugin can be developed before it is listed in an internal marketplace.

Versioning is the unglamorous half

Releases are identified so that a bug report can name the version it came from, so that an update can be tested before wider adoption, and so that a team has somewhere to retreat to. Microsoft is careful to add that a rollback plan needs retained releases and a rehearsed recovery procedure for the client and installation source in use. Its engineers typically work in VS Code and the GitHub Copilot CLI, both of which support plugins.

Our opinion

The interesting claim here is not that an assistant can follow instructions, it is that the instructions deserve a release process. Versioning, rollback and a marketplace entry are dull answers to a problem that bites quietly: once shared agent configuration is copied between repositories it stops being maintainable and starts being folklore. The boundary Microsoft draws is the part worth stealing, because it keeps the reusable workflow in the package and refuses to put application context there too. A plugin that shipped a customer's architecture decisions would become a liability the first time those decisions changed. The caveat is that this is a vendor describing its own work for one customer, so confidence comes from the engineering reasoning rather than from a measurement of the outcome.