Claude Code Plugins: What They Are & How to Use Them

A Claude Code plugin is a folder that ships more than one kind of extension at once. Where a skill is a single SKILL.md file teaching Claude one behavior, a plugin can bundle skills, subagents, hooks, slash commands, and even an MCP server, and install all of it with one command. It’s the difference between handing someone a recipe card and handing them a stocked kitchen.

Anthropic added plugins to Claude Code in late 2025, and they solved a real problem: teams weren’t installing one skill at a time, they were assembling setups. A “backend engineer” configuration might need a debugging skill, a code-review subagent, a pre-commit hook, and a database MCP connection. Before plugins, that meant four separate installs and four places for the setup to drift out of sync. A plugin makes it one.

We test and catalog Claude skills at SkillProof, and plugins are the next layer up from what we usually review: a packaging format, not a behavior. This guide covers what’s actually inside a plugin, how the marketplace system works, and the same trust question we’ve been asking about skills since we started, now applied to something with a lot more surface area.

What plugins actually package

Four ingredient types can show up inside a single plugin, and most real plugins use more than one:

• Skills — markdown instructions that load when a task matches, the same format covered in what Claude skills are.
• Subagents — separate Claude instances with their own system prompt and context window, useful for delegating a noisy or parallel task.
• Hooks — shell commands that fire automatically on events like a file save, a commit, or a tool call finishing. A lint-on-save hook is the classic example.
• Slash commands — custom commands like /deploy or /standup that run a predefined prompt or script when a teammate types them.
• MCP servers — a connection to an external tool or data source, configured once inside the plugin instead of by hand in every project.

A plugin doesn’t need all five. Plenty ship just a couple of skills, or a single hook plus the command that triggers it. What makes it a plugin rather than a loose collection of files is that it installs as one unit, with one manifest describing what’s inside.

Plugins vs skills: the npm-package analogy

The cleanest way to think about this: a skill is a function, a plugin is a package.

A single skill teaches Claude one behavior, whether that’s formatting meeting notes or auditing an SEO page. It has no dependencies and no configuration beyond its own markdown. That’s by design: a skill written to cover several unrelated tasks tends to trigger unreliably on all of them, since its description can’t be specific about any single one.

A plugin is the distribution unit around that behavior. In the npm world, a function doesn’t ship by itself; it ships inside a package with a package.json, a version number, and maybe a couple of other functions that belong together. A plugin plays the same role for Claude Code: it’s the thing with a name, a version, an author, and a manifest, and the skills, hooks, and commands inside it are the exports.

This distinction matters for a practical reason. When something breaks, “the skill’s trigger is too vague” and “the plugin’s hook is running the wrong shell command” are different bugs with different fixes. Blaming the whole plugin for one bad skill inside it, or vice versa, wastes time. Read the manifest first to see what actually shipped before you diagnose anything.

It also means the two units get evaluated differently. A skill lives or dies on trigger quality and whether its output beats Claude’s default. A plugin lives or dies on whether its parts cooperate: does the hook fire before or after the skill needs its output, does the command call an MCP server that’s actually configured, does installing it clash with something you already have.

Anatomy of a plugin

Every plugin needs a .claude-plugin directory at its root containing plugin.json, the manifest. Everything else (skills/, agents/, hooks/, commands/, .mcp.json) sits alongside it as plain folders that Claude Code knows to look for by convention.

Here’s a small but complete plugin, annotated:

team-standards/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
└── commands/
    └── deploy.md

// .claude-plugin/plugin.json
{
  "name": "team-standards",
  "version": "1.2.0",
  "description": "Our lint hook, review skill, and deploy command in one install.",
  "author": "platform-team"
}

The manifest is deliberately thin. It identifies the plugin and its version; it doesn’t enumerate every file inside, because Claude Code discovers skills/, hooks/, and commands/ by their folder names automatically.

// hooks/hooks.json
{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./scripts/check-branch.sh" }]
    }
  ]
}

This hook fires before any Bash tool call and can block it, which is how a plugin enforces something like “never run destructive git commands on main” without relying on Claude remembering to check.

<!-- commands/deploy.md -->
---
description: Run our deploy checklist against staging
---

Verify the branch is not main, confirm migrations are applied,
then run `./deploy.sh staging`. Report the deploy log summary.

Typing /deploy runs exactly this, every time, worded identically for every teammate who installs the plugin. That consistency is the entire pitch: three components, one version number, one install command, and no one’s local setup drifting from anyone else’s.

A separate file, marketplace.json, is not part of the plugin itself. It’s the index a marketplace repository publishes so Claude Code knows what plugins live there and where to fetch each one from. One repo’s marketplace.json can list dozens of unrelated plugins; think of it as the registry, with plugin.json as the individual package inside it.

Installing from marketplaces

Getting a plugin onto your machine is two commands. First, point Claude Code at a marketplace:

/plugin marketplace add anthropic/plugins

This reads that repository’s marketplace.json and adds every plugin it lists to what you can browse. Then install one:

/plugin install code-standards@anthropic

The @anthropic part specifies which marketplace to pull from, since you can have several added at once and the same plugin name could theoretically exist in more than one. Claude Code fetches the plugin’s files, registers its skills and commands, and wires up any hooks or MCP servers it declares.

Here’s the part that should sound familiar if you’ve read anything else we’ve written: nobody reviews these. Adding a marketplace means trusting whoever maintains that repository, and installing a plugin from it means trusting every file the plugin brings in, including hooks that run shell commands and MCP servers that get network access. This is the exact trust problem we’ve documented for skills, except a plugin has more moving parts, which means more places for something bad to hide. A skill can only be persuasive text loaded into context. A plugin can also be a hook that executes on every commit whether you’re watching or not.

Our security checklist for skills applies here with one addition. Before installing a plugin:

1. Read the manifest and every file it references before running the install command, not after. A plugin.json claiming to be a “deploy helper” that also declares an MCP server pointing at an unfamiliar domain is a signal worth stopping on.
2. Pin the version. Install code-standards@1.2.0, not whatever latest resolves to next Tuesday. A plugin that changes its hook behavior after you’ve already trusted it is worse than one that was bad from day one, because you won’t be looking.
3. Check what hooks and commands ship, specifically. Hooks run automatically, without you typing anything, on events like tool calls and file saves. That’s the component most worth reading in full, since it’s the one that acts without a prompt from you in the moment.
4. Treat an MCP server bundled in a plugin like any other MCP server: it gets real network access and often real credentials. Bundling it inside a plugin doesn’t make it safer, it just makes it easier to install without noticing it’s there.

We cover the full threat model, including what a malicious hook or skill actually looks like in practice, in our skills security guide. Everything there about treating third-party instructions like a dependency you haven’t audited applies to plugins, only with a wider blast radius.

When to package your team’s setup as a plugin

The clearest signal you’re ready for a plugin: you’ve written the same setup instructions in a README, a Slack pin, and an onboarding doc, and they’re already out of sync in two of the three places.

Take a concrete case. A platform team wants every engineer’s Claude Code session to enforce the same standards: no direct commits to main, a consistent code-review pass before merge, and a one-command deploy to staging. Bundled separately, that’s a hook someone has to remember to add to settings.json, a skill someone has to remember to install, and a command someone has to remember exists. Bundled as a team-standards plugin, it’s one line:

/plugin install team-standards@our-org

and every new hire gets the branch-protection hook, the code review checklist skill, and the /deploy command in one step, versioned together so an update to the deploy script and an update to the review criteria ship in the same release instead of drifting apart.

The reverse signal matters too: if your setup is a single skill with no hooks, commands, or MCP dependency, packaging it as a plugin adds a manifest and a marketplace listing for no benefit. Publish it as a skill on its own, the way we cover in what Claude skills are, and reach for a plugin only once there’s more than one moving part to keep in sync. If the MCP server is the complicated part of your setup, our notes on building one live in MCP Builder, which is worth a look before you decide whether a plugin needs its own server at all versus pointing at one that already exists.

Our own 30-minute Claude Code setup guide walks through building this layer by layer for an individual; a team plugin is the same layering exercise, just versioned and shared instead of assembled by hand on each laptop.

The ecosystem in 2026, honestly

Plugins are young, and it shows. The marketplace format only stabilized a few months ago, which means most marketplace.json files in the wild were written against an early draft of the spec and haven’t been touched since. Documentation quality varies enormously: some plugin repos have a clear README with a version history, others are a single commit with no explanation of what the bundled hook actually does.

Fragmentation is the bigger issue. Because a plugin can declare its own skills rather than referencing ones you already have installed, the same behavior gets reinvented across a dozen different plugins with a dozen different quality bars. We’ve seen a code-review skill bundled inside three unrelated plugins, none aware the others exist, each written to a different standard.

That produces the same quality lottery we documented across community skills generally: about half of what we test fails on the first try, whether from an install script that assumes a directory structure the author never verified on a clean machine, or a hook that silently no-ops because it was written against an earlier version of the hook API. A plugin doesn’t fix that failure rate. It just bundles more components that can each fail independently, and a plugin only works if every piece inside it does.

None of that means skip plugins. It means apply the same skepticism you’d apply to any dependency: check who maintains it, check when it was last updated, and don’t install something with three components when you only need one of them. The packaging format is genuinely useful for keeping a team in sync. It isn’t a substitute for reading what you’re installing.

FAQ

What’s the difference between a Claude Code plugin and a skill?

A skill is one behavior in one markdown file. A plugin is a distribution unit that can bundle several skills alongside subagents, hooks, slash commands, and an MCP server, all installed together with one command and one version number. Every plugin’s skills are still skills underneath; the plugin is just the packaging around them.

How do I install a Claude Code plugin?

Add the marketplace first with /plugin marketplace add <repo>, then install a specific plugin from it with /plugin install <plugin-name>@<marketplace>. Pin a version rather than installing whatever the marketplace currently points to as latest, so an update doesn’t silently change behavior you already reviewed.

Are Claude Code plugins safe to install?

Treat them the way you’d treat any third-party dependency, and more carefully than a plain skill, since a plugin can also ship hooks that run shell commands automatically and MCP servers with real network access. Read the manifest and every bundled file before installing, not after. Our skills security guide covers the underlying threat model in detail.

Can I put my own MCP server inside a plugin?

Yes. A plugin can declare an .mcp.json that configures an MCP server as part of the install, so teammates get the connection set up automatically instead of configuring it by hand in every project. If you’re building the server itself rather than just wiring one up, see MCP Builder for the build side of that.

Where do I find Claude Code plugins to install?

Anthropic maintains an official marketplace, and community marketplaces have grown quickly since the format launched. Quality varies as much as it does across community skills generally, so check the manifest, check when it was last updated, and prefer plugins from maintainers who document what’s actually inside before you add their marketplace.