Claude Code Plugins: Install, Build & Share (2026)

Claude Code pluginsare installable, shareable bundles that package any combination of skills, subagents, slash commands, hooks, and MCP servers into a single unit — so one install adds a whole capability set to a project instead of you wiring up each piece by hand. They’re managed with the /plugin command, enabled per-project or globally, and distributed through git-based marketplaces. In short, plugins are how skills, subagents, and commands get distributed and versioned across a team.

What are Claude Code plugins?

A plugin is a bundle. Where a single skill teaches Claude one capability and a single subagenthands off one kind of task, a plugin lets you package several of those together — skills, subagents, slash commands, hooks, and MCP server configuration — into one thing you install once. That’s the whole point: instead of telling a teammate “copy these three skill folders, add this agent, register this MCP server,” you tell them to install one plugin.

Plugins are managed with the /plugincommand and tracked in your settings — for example an enabledPlugins entry in settings.json— so a plugin can be turned on for a single project or globally across everything you work on. The plugin system entered public beta around October 2025; it’s a fast-moving area, so treat specifics here as a snapshot as of mid-2026 and check the current docs.

What can a Claude Code plugin bundle?

A plugin can contain any mix of five component types. Each maps to a directory (or a piece of config) inside the plugin:

None of these is mandatory. A plugin can be a single skill, or a commands-only bundle, or a full kit with all five. The bundle is the feature — whatever capabilities belong together, ship together.

What does the plugin structure look like?

A plugin is a directory with a .claude-plugin/plugin.json manifest at its root, plus the component directories for whatever it bundles. The manifest is small — name, description, version, and author are the core fields:

my-plugin/
  .claude-plugin/
    plugin.json        # manifest
  commands/            # slash commands
  agents/              # subagents
  skills/              # skills (each <name>/SKILL.md)
  hooks/               # event hooks

# .claude-plugin/plugin.json
{
  "name": "my-plugin",
  "description": "Team conventions: skills, commands, and a review agent",
  "version": "1.0.0",
  "author": "Your Team"
}

Note the nesting: the manifest lives under .claude-plugin/, but the component directories sit at the plugin root next to it. Inside skills/, each skill is its own folder with a SKILL.md (YAML frontmatter plus a Markdown body), exactly as a standalone skill would be; subagents live as agents/<name>.md files.

How do you install a plugin from a marketplace?

Two steps. First add the marketplace that hosts the plugin, then install the plugin by name and marketplace:

# 1. Add a marketplace (a git repo or local dir)
/plugin marketplace add owner/repo

# 2. Install a plugin from it
/plugin install my-plugin@marketplace-name

# Browse and manage interactively
/plugin

1. 1

   Add a marketplace

   Point Claude Code at the git repo (or local directory) that hosts the plugin with /plugin marketplace add owner/repo.
2. 2

   Install a plugin

   Pull the bundle in by name and marketplace with /plugin install my-plugin@marketplace-name.
3. 3

   Enable it

   Turn the plugin on per-project or globally; Claude Code records the choice in your settings (for example under enabledPlugins). The /plugin menu also lets you list, enable, disable, and remove plugins interactively.

Once installed, you enable a plugin per-project or globally, and Claude Code records that choice in your settings (for example under enabledPlugins). The same /plugin menu lets you list, enable, disable, and remove plugins without editing files by hand.

What is a plugin marketplace?

A marketplace is a git repository (or a local directory) that contains a .claude-plugin/marketplace.json file listing the plugins it offers. That’s the entire mechanism: point Claude Code at the repo with /plugin marketplace add, and every plugin in that marketplace.json becomes installable.

Crucially, the model is decentralized. Anyone can host a marketplace — a company can publish an internal one, an open-source project can ship a public one, and you can run a private repo for your own team. There is no single official app-storegatekeeping plugins; discovery and trust are up to you and whoever publishes the repo. For more on how shared skill libraries get distributed this way, see the Claude skills marketplace guide.

How do you build your own plugin?

Building a plugin is mostly arranging files. Create a directory, add a .claude-plugin/plugin.json with at least a name, description, version, and author, then drop in whichever component directories you need:

• Add skills under skills/<name>/SKILL.md — the same SKILL.md format you’d write standalone.
• Add subagents as agents/<name>.md files, one per agent.
• Add slash commands in commands/ and hooks in hooks/.
• Wire MCP serversthrough the plugin’s configuration so they come along with the bundle.

To distribute it, put the plugin in a git repo, add a marketplace.json that lists it, and share the repo. Teammates run /plugin marketplace add and /plugin installand they’re running the same setup you are — versioned, because the manifest carries a version and the repo carries history.

Plugins vs skills vs subagents

These three are often confused because plugins contain the other two. The distinction is scope: a skill is one capability, a subagent is one delegated worker, and a plugin is the package that ships a set of them.

You don’t need a plugin to use a skill — skills work fine on their own from ~/.claude/skills/ or a project’s .claude/skills/. The plugin exists for the moment you want to hand that whole setup to someone else and keep it in sync. For the deep dive on each piece, see the skills guide and the subagents guide.

How do you distribute plugins across a team?

Plugins solve the distributionhalf of the problem — one install, one version, shared from a git repo. But teams rarely live in one tool. The same conventions that go into a Claude Code plugin often need to exist as Cursor rules, Windsurf rules, and Copilot instructions too, and keeping those in sync by hand is exactly the drift problem a plugin’s single bundle was meant to avoid.

That’s the gap Skillwrightfills. You keep one canonical library of rules and skills, and compile it out to every IDE format — so the capabilities you package into a Claude Code plugin and the rules your other tools read all come from the same source and never drift. Start from ready-made templates, and read how to manage AI coding rules across tools for the cross-tool workflow that complements a plugin-based Claude Code setup.

Frequently asked questions