# Claude Code Plugins: Install, Use, and Build Your Own

> How Claude Code plugins work — what they can bundle, the /plugin and marketplace commands, the plugin.json manifest, and building and testing your own.

Plugins are Claude Code's distribution format: one installable package that can bundle skills, agents, slash commands, hooks, MCP servers, and LSP config. Install from marketplaces with /plugin (Anthropic's official one is preregistered), add others with /plugin marketplace add owner/repo, and build your own with a .claude-plugin/plugin.json manifest tested via claude --plugin-dir.

For most of Claude Code's life, sharing your setup meant a README: "copy these files into `.claude/agents/`, add this to settings, run `claude mcp add`…" **Plugins** replace that with a real distribution format — one installable, versioned package that can carry your whole toolkit.

## What a plugin can bundle

Any combination of:

- **Skills** — on-demand procedures (`skills/<name>/SKILL.md`), invoked as `/plugin-name:skill-name`
- **Agents** — subagent definitions (`agents/*.md`)
- **Slash commands** — (`commands/*.md`, the older flat format; new plugins should prefer skills)
- **Hooks** — lifecycle automation (`hooks/hooks.json`), same shape as [settings hooks](/guides/configuration/claude-code-hooks)
- **MCP servers** — a bundled `.mcp.json`, so installing the plugin connects its integrations
- **LSP servers** — code-intelligence config that gives Claude go-to-definition instead of text search
- Output styles, themes, and background monitors round out the list.

That composability is the point: a "Sentry debugging" plugin can ship the MCP server *and* a subagent that knows how to use it *and* the hook that triggers it — one install instead of three setup steps.

## Installing plugins

`/plugin` opens the interactive browser (Discover / Installed / Marketplaces tabs). The direct commands:

```text
/plugin install <name>@<marketplace>     # install
/plugin disable <name>                   # switch off without uninstalling
/plugin details <name>                   # see components and context cost
/plugin marketplace add <source>         # register a marketplace
```

Anthropic's official marketplace (`claude-plugins-official`) is preregistered — it carries first-party integrations (GitHub, Figma, Slack, language LSPs, and more). A marketplace is just a repo with a `marketplace.json`, so adding more is one command with a GitHub `owner/repo`, a git URL (private/SSH works), a local path, or a hosted JSON URL. Real-world examples you can try today: `/plugin install figma@claude-plugins-official` for Figma's design tools, or `/plugin marketplace add cloudflare/skills` for Cloudflare's.

Two details that matter day-to-day:

- **Namespacing.** Plugin components are prefixed — `/commit-commands:commit`, `Agent(security-plugin:auditor)` — so same-named components from different plugins never collide.
- **Scopes.** Like settings, plugins install at user scope by default; `--scope project` records them for the whole repo, so teammates get the team baseline after a one-time trust prompt.

## Building your own

A plugin is a directory; only the manifest lives in the `.claude-plugin/` folder, everything else sits at the root:

```text
my-plugin/
├── .claude-plugin/
│   └── plugin.json        # the manifest — only this goes in .claude-plugin/
├── skills/
│   └── release-notes/
│       └── SKILL.md
├── agents/
│   └── reviewer.md
├── hooks/
│   └── hooks.json
└── .mcp.json              # MCP servers to connect on install
```

The manifest needs one field; the rest is metadata and overrides:

```json
{
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "Release tooling: changelog skill, reviewer agent, format hooks",
  "author": { "name": "Your Team" }
}
```

Three variables make bundled code portable: `${CLAUDE_PLUGIN_ROOT}` (the plugin's install directory — use it in hook commands and MCP configs), `${CLAUDE_PLUGIN_DATA}` (a persistent data directory that survives updates — caches, venvs), and `${CLAUDE_PROJECT_DIR}` (the project being worked on).

**Test locally, then publish:**

```bash
claude --plugin-dir ./my-plugin    # load it for one session
# iterate without restarting: /reload-plugins
claude plugin validate ./my-plugin # lint the manifest before shipping
```

Publishing is listing it in a marketplace: add a `marketplace.json` to any repo naming your plugins and their sources, and consumers run `/plugin marketplace add your-org/your-repo`. For a team, that repo becomes the tooling registry — update the plugin, everyone pulls the new version.

> [!TIP]
> Don't hand-write the scaffolding — the [plugin-scaffolder](/skills/workflow/plugin-scaffolder) skill generates the directory structure, manifest, and a working sample component from a description of what your plugin should do.

## When to reach for a plugin

Use the lighter mechanisms when they're enough — a single [skill](/guides/skills/writing-your-first-skill) for one procedure, a [custom agent](/guides/getting-started/writing-a-custom-agent) file for one specialist, plain [settings](/guides/configuration/claude-code-settings-permissions) for one project's config. Reach for a plugin when the value is in the **bundle** (skill + agent + hook + MCP that work together) or in **distribution** (more than one person, more than one repo, versioned updates). That's also why plugins are how vendors now ship Claude Code integrations — and why your internal platform team probably wants one.

---

_Source: https://agentscamp.com/guides/configuration/claude-code-plugins — Guide on AgentsCamp._