Agent Plugins 1.0 Implementation Service Guide

An Agent Plugins 1.0 implementation service packages reusable agent instructions and tool configuration so compatible clients can discover the same capability without maintaining separate bundles for every environment. The engineering work is modest only when the underlying skill, server, permissions, tests, distribution, and ownership are already mature.

GitHub announced Agent Plugins 1.0 support across VS Code, Copilot CLI, the Copilot SDK, and the Copilot app in August 2026. The open standard packages skills and MCP server configuration while allowing client-specific behavior under a namespaced directory.

Decide whether portability solves a real problem

Start by identifying duplicated maintenance. A team may have copied the same deployment runbook, issue workflow, or data tool configuration into several agent clients. A portable package can reduce drift when users need the same capability across those surfaces.

Good candidates have:

• A bounded job with repeatable inputs and outputs.

• Stable instructions already used successfully by a team.

• A tool server with narrow, documented capabilities.

• Clear ownership and a versioning process.

• Tests that can run outside one client interface.

• A defined audience and distribution method.

Avoid packaging an experimental prompt simply because the format is available. Distribution multiplies the effect of unclear instructions and excessive permissions.

Inventory the existing capability

Separate portable components from client-specific conveniences. The skill may describe a release workflow, while one client provides custom commands or interface extensions that do not translate elsewhere.

Document:

1. Skill instructions and referenced assets.

2. MCP servers, commands, URLs, and authentication needs.

3. Custom agents, rules, hooks, commands, and extensions.

4. Required environment variables and local dependencies.

5. Supported operating systems and execution environments.

6. Current marketplaces or direct-install paths.

7. Consumers and versions in active use.

8. Security review, test evidence, and accountable maintainers.

This inventory defines the migration boundary and prevents a “portable” package from silently losing critical behavior.

Build the package structure deliberately

GitHub's implementation guidance describes adding a schema reference to plugin.json, placing skills under skills/, keeping MCP configuration in mcp.json, and moving GitHub-specific content beneath com.github.copilot/. Follow the current Agent Plugins specification as the source of truth during implementation.

The manifest should expose only what users need to understand and install the package. Keep secrets out of configuration and document how each client supplies credentials securely.

Review:

• Stable plugin identifier and semantic version.

• Human-readable purpose and supported use cases.

• Skill paths that remain valid after packaging.

• Server commands that avoid shell interpolation.

• Explicit environment requirements.

• Namespaced client-specific components.

• License, ownership, support, and issue-reporting details.

• Compatibility and minimum-version expectations.

Validate the package from its distributed archive, not only the source directory.

Treat MCP configuration as executable authority

An MCP server may read files, query internal systems, invoke APIs, or change external state. Portability can expose that authority in more clients, so permissions need a separate review for each execution environment.

Create a capability matrix showing:

• Every tool and its side effects.

• Required filesystem and network access.

• Credential type, scope, lifetime, and owner.

• User and tenant authorization rules.

• Confirmation requirements for consequential actions.

• Logging and sensitive-output controls.

• Timeout, retry, and duplicate-action behavior.

• Emergency disable and revocation procedures.

Use allowlists to restrict servers by known command, URL, or identity. A plugin marketplace approval should not automatically approve every server the package may reference.

The code review agent skills guide provides a deeper review of instruction ownership, permissions, updates, and evaluation.

Test across compatible clients

One valid manifest does not prove equivalent behavior. Clients can differ in supported features, operating system, tool confirmation, path handling, environment injection, and user interface. Define a portability test suite around outcomes.

Include:

• Fresh installation from the intended marketplace or archive.

• Skill discovery from a realistic request.

• Missing dependency and missing credential behavior.

• Allowed and denied tool calls.

• Paths containing spaces or platform-specific separators.

• Client-specific behavior isolated to its namespace.

• Upgrade from the previous plugin version.

• Uninstall and cleanup without losing user data.

• Offline or unavailable server recovery.

• Audit attribution showing which skill or server contributed.

Run tests on every supported client before claiming compatibility. Document partial support rather than hiding it behind a broad logo list.

Design marketplace and enterprise governance

Organizations need to know who may install plugins, which marketplaces are trusted, and how team-specific exceptions are approved. GitHub documents managed settings for enabled plugins, known marketplaces, and strict marketplace restrictions.

A governance plan should define:

1. Approved publishers and provenance checks.

2. Review requirements for new and updated packages.

3. Marketplace allowlists and team overrides.

4. MCP server allowlists independent of plugin approval.

5. Version pinning or controlled update rings.

6. Vulnerability reporting and revocation.

7. Inventory of installations by team and client.

8. Retirement and replacement procedures.

For broader multi-agent ownership questions, see the multi-agent system architecture guide.

Plan migration without breaking current users

Existing packages can remain supported, so migration does not need to be a forced cutover. Publish a compatible preview, invite representative users from each client, and compare outcomes with the current installation.

A safe sequence is:

• Freeze unrelated feature work during packaging.

• Produce the portable structure and validation checks.

• Preserve existing identifiers and behavior where possible.

• Release to an internal or limited marketplace channel.

• Collect installation, invocation, and tool-failure evidence.

• Fix compatibility gaps before wider discovery.

• Publish upgrade and rollback instructions.

• Set a review date for retiring duplicate packages.

Track adoption so maintainers know which versions still require security support.

Make updates reviewable

A plugin update can change instructions, server endpoints, tool schemas, hooks, commands, or permissions. Generate a release summary that separates these categories and highlights authority changes.

Require additional approval when an update adds network destinations, new tools, broader filesystem access, credential scopes, automatic hooks, or new marketplaces. Re-run adversarial and compatibility tests before promotion.

The official GitHub weekly release summary also shows that agent tooling changes frequently. Versioned tests and controlled update rings keep portability from turning into synchronized breakage.

What an implementation partner should deliver

Expect a capability inventory, migration boundary, valid package, security matrix, compatibility suite, marketplace policy, staged rollout, update process, owner documentation, and rollback plan.

The engagement should leave the package and publishing accounts under client control. It should also record which behaviors remain client-specific and why.

Frequently asked questions

Does one package behave identically everywhere?

Not automatically. The standard improves discovery and packaging portability, while clients can still differ in supported extensions, confirmations, environments, and interface behavior. Test every claimed surface.

Can a plugin include credentials?

Credentials should not ship inside the package. Document the required secret names and use each environment's approved secure injection mechanism with minimum scopes.

Should existing plugins migrate immediately?

Prioritize packages suffering from duplicated maintenance or needed across several compatible clients. Stable single-client packages can migrate after value and compatibility are demonstrated.

Explore Voquarn's agent integration services or book a plugin architecture review to turn an existing capability into a governed portable package.