title	Plugins for {% data variables.product.prodname_copilot %}
shortTitle	Plugins
allowTitleToDifferFromFilename	true
intro	Plugins are installable packages that extend {% data variables.product.prodname_copilot_short %} with reusable agents, skills, hooks, and integrations.
product	{% data reusables.gated-features.copilot-cli %}<br><br>{% data reusables.gated-features.copilot-cloud-agent %}<br><br>{% data reusables.gated-features.github-app %}<br><a href="https://github.com/features/copilot/plans?ref_product=copilot&ref_type=purchase&ref_style=button" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Sign up for {% data variables.product.prodname_copilot_short %}</span> {% octicon "link-external" height:16 %}</a>
versions	feature copilot
contentType	concepts
category	Learn about Copilot Learn about Copilot CLI
docsTeamMetrics	copilot-cli
redirect_from	/copilot/concepts/agents/copilot-cli/about-cli-plugins /copilot/concepts/agents/about-plugins

Plugins let you install related customizations together instead of setting up each one separately. For example, a testing plugin could combine a skill for running tests, a review agent, and an MCP server for a test-reporting service.

Where you can use plugins

You can use plugins in:

• The {% data variables.copilot.github_copilot_app %}.
• {% data variables.copilot.copilot_cli %}.
• {% data variables.copilot.copilot_cloud_agent %}.
• {% data variables.product.prodname_vscode %}. For supported components and installation, see Agent plugins in {% data variables.product.prodname_vscode_shortname %}.

A plugin can contain components that only work in a particular surface. Check that the plugin supports the surface you use. For example, the LSP server configuration described in this category is for {% data variables.copilot.copilot_cli_short %}.

The component paths and directory examples below describe plugin formats for {% data variables.copilot.copilot_cli_short %}. Other surfaces can support different components.

What plugins contain

A plugin can contain some or all of the following components. The locations of these components depend on the plugin format:

• Custom agents — Specialized AI assistants (*.agent.md files in agents/)
• Skills — Task-specific instructions, scripts, and resources (skills subdirectories in skills/, containing a SKILL.md file)
• Hooks — Event handlers that intercept agent behavior (a hooks.json file in the plugin root, or in hooks/)
• Extensions — Code that adds capabilities such as tools and slash commands in supported surfaces
• MCP server configurations — Model Context Protocol integrations
• LSP server configurations — Language Server Protocol integrations (an lsp.json file in the plugin root, or in .github/)

Plugin formats

{% data variables.product.prodname_copilot_short %} supports two plugin formats:

• Agent Plugins 1.0 is a portable format for sharing skills and MCP server configurations across compatible clients. To use this format, set $schema in plugin.json to https://agent-plugins.org/schemas/1.0.0/plugin.schema.json. Skills are discovered from skills/, and MCP server configuration is discovered from mcp.json at the plugin root. These locations cannot be configured in the manifest. Choose Agent Plugins 1.0 when you want to make skills and MCP servers portable.
• Legacy {% data variables.product.prodname_copilot_short %} plugins do not declare the Agent Plugins $schema. They use the existing manifest fields and component discovery behavior, including configurable component paths and MCP configuration in .mcp.json, .github/mcp.json, or the mcpServers manifest field. Choose the legacy format when you need configurable component paths or are maintaining an existing {% data variables.product.prodname_copilot_short %}-specific plugin.

For a new plugin, use Agent Plugins 1.0 unless you require configurable component paths. Use the legacy format primarily for existing legacy plugins.

Both formats are supported. Adding $schema changes how {% data variables.product.prodname_copilot_short %} interprets the manifest and discovers components. Plugins without $schema continue to load as legacy plugins.

How plugins are structured

A plugin is a directory with a specific structure and a plugin.json manifest file. Agent Plugins 1.0 requires the manifest at the plugin root. Legacy plugins support additional manifest locations. The manifest gives the plugin a name and metadata. Depending on the format, it can also point to components. Alongside the manifest, the directory can contain agents, skills, hooks, MCP server configurations, and LSP server configurations.

Agent Plugins 1.0 structure

Agent Plugins 1.0 stores skills and MCP servers in standard locations so compatible clients can discover them. Other components, including agents, hooks, commands, and LSP servers, are client-specific. {% data variables.product.prodname_copilot_short %} reads these components from the com.github.copilot directory. Other clients ignore this directory, so the same plugin can combine shared skills and MCP servers with {% data variables.product.prodname_copilot_short %}-specific components.

An Agent Plugins 1.0 directory can look like this:

my-plugin/
├── plugin.json               # Required manifest
├── skills/                   # Skills (optional)
│   └── deploy/
│       └── SKILL.md
├── mcp.json                  # MCP server config (optional)
└── com.github.copilot/       # Copilot components (optional)
    ├── agents/
    │   └── helper.agent.md
    ├── commands/
    ├── rules/
    ├── hooks/
    │   └── hooks.json
    └── lsp.json

The manifest must include the Agent Plugins 1.0 $schema. For supported top-level manifest fields, name requirements, and component locations, see Agent Plugins 1.0 manifest fields.

Legacy plugin structure

A legacy {% data variables.product.prodname_copilot_short %} plugin directory can look like this:

my-plugin/
├── plugin.json           # Required manifest
├── agents/               # Custom agents (optional)
│   └── helper.agent.md
├── skills/               # Skills (optional)
│   └── deploy/
│       └── SKILL.md
├── hooks.json            # Hook configuration (optional)
├── .mcp.json             # MCP server config (optional)
└── lsp.json              # LSP server config (optional)

For the full set of fields you can include in the manifest, see AUTOTITLE. For step-by-step guidance on authoring a plugin, see AUTOTITLE.

Why use plugins?

Plugins provide the following benefits:

• Reusability across projects
• Team standardization of {% data variables.product.prodname_copilot_short %} configuration
• Share domain expertise (for example, by providing the skills of a Rails expert, or a Kubernetes expert)
• Encapsulate complex MCP server setups

Where can I get plugins?

You can install plugins from:

• A marketplace
• A repository
• A local path

A marketplace is a location where developers can publish, discover, install, and manage plugins. It's a bit like an app store—but for plugins.

Examples of marketplaces include:

• copilot-plugins (added by default)
• awesome-copilot (added by default)
• claude-code-plugins
• claudeforge-marketplace

How you install a plugin depends on which client you're using:

• In {% data variables.copilot.copilot_cli_short %}, you can install plugins using the copilot plugin install command or the /plugin install slash command, or by adding the plugin to the enabledPlugins field of either a user-level ~/.copilot/settings.json file or a repository-level .github/copilot/settings.json file. See AUTOTITLE.
• In {% data variables.copilot.copilot_cloud_agent %}, you install plugins by adding them to the enabledPlugins field of the repository's .github/copilot/settings.json file. To install plugins from a marketplace that isn't registered by default, you can also add the marketplace to the extraKnownMarketplaces field in the same file.
• In the {% data variables.copilot.github_copilot_app %}, click Customize, then click Plugins to browse marketplaces and install plugins.
• In {% data variables.product.prodname_vscode %}, use the plugin marketplace commands described in the {% data variables.product.prodname_vscode_shortname %} documentation linked above.

Enterprise administrators can define plugin standards that apply to users on the enterprise's {% data variables.product.prodname_copilot_short %} plan, including specifying additional marketplaces and plugins that are automatically installed. See AUTOTITLE.

How plugin marketplaces work

A plugin marketplace is a registry of plugins that you can browse and install from. A marketplace can be hosted in a repository on {% data variables.product.prodname_dotcom_the_website %}, in any other online Git hosting service, or on your local or shared file system.

A marketplace is defined by a marketplace.json file, which provides metadata about the marketplace and lists the plugins it makes available. Each entry in the marketplace's plugins array describes a plugin—including its name, description, version, and the path to the plugin's directory.

Because plugins in a marketplace are versioned, marketplaces make it easy to discover, install, and update plugins, and to share them across a team. For step-by-step guidance on creating a marketplace, see AUTOTITLE.

Plugins compared with manual configuration

Any functionality that you could add with a plugin, you could also add by configuring {% data variables.product.prodname_copilot_short %} manually—for example, by adding custom agent profiles or MCP servers. However, plugins provide several advantages over manual configuration:

Feature	Manual configuration in a repository	Plugin
Scope	Single repository	Any project
Sharing	Manual copy/paste	Install command or enabledPlugins entry
Versioning	Git history	Marketplace versions
Discovery	Searching repositories	Marketplace browsing

Further reading

• AUTOTITLE
• AUTOTITLE
• AUTOTITLE
• AUTOTITLE