Claude Code plugins — what they are, how to install them, and which are worth it

What a Claude Code plugin actually is

A plugin is a directory Claude Code loads at startup. It can contain:

• Skills — slash commands you invoke manually (e.g. /figma:inspect), invoked on demand
• Subagents — purpose-built agents with their own system prompt and tool restrictions
• MCP servers — connections to external APIs and data (Figma, GitHub, Stripe, databases)
• Hooks — event handlers that fire automatically at points like file save or after every tool call
• Background monitors — persistent watchers (e.g. a log tail) that notify Claude as events arrive
• LSP servers — language intelligence for real-time diagnostics and completions

Most plugins you'll install use two or three of these together. The Figma plugin, for example, bundles an MCP server (to read design files) and several skills (to extract specs, export tokens, generate code from a selected frame) — instead of wiring the MCP manually and asking Claude to figure out the workflow.

How to install a Claude Code plugin

There are two public marketplaces you work with in practice:

Official marketplace — registered automatically when you first open Claude Code. Contains curated plugins built or reviewed by Anthropic.

/plugin install figma@claude-plugins-official

Community marketplace — third-party submissions that pass automated safety screening. Add it once, then install from it:

/plugin marketplace add anthropics/claude-plugins-community
/plugin install brand-voice@claude-community

You can also point at any GitHub repository directly. Team repos become installable the same way — host a marketplace.json in a private repo and distribute to your team without touching the public directory.

After installing, the plugin loads on the next session start. Run /reload-plugins to pick up changes without restarting.

Skills vs standalone .claude/ configuration

You might already have slash commands in .claude/commands/ or hooks in .claude/settings.json. Those are standalone configuration — personal, project-scoped, not shareable without copying files manually.

A plugin is the same thing packaged for distribution. The practical difference:

If you're building something for yourself, standalone is faster. Once it works and you want teammates to use it, convert to a plugin. Anthropic's docs show a claude plugin init my-tool scaffold that handles the manifest and directory layout.

Which plugins are actually worth installing

As of mid-2026, the Anthropic official marketplace has ~33 verified plugins; the community marketplace has grown past 100. Most aren't useful for the maker/PM use case. Four that consistently hold up:

Figma (907,000+ installs, Anthropic-verified) — connects directly to your Figma files. Once installed, you can ask Claude to extract design specs, generate code from a selected frame, or export design tokens. Saves the copy-paste loop between Figma and your editor. Requires authentication on first use.

Code Review (372,000+ installs, Anthropic-verified) — adds a /code-review skill that runs structured review on a PR diff or file. Useful for solo makers who want a second pass before shipping; the output is more opinionated than asking Claude ad hoc.

Context7 (368,000+ installs) — pulls current library documentation into context before Claude writes code, so it isn't writing against stale training data for fast-moving dependencies like React 19 or Next.js 15.

Superpowers (821,000+ installs) — a broad bundle. Genuinely useful for standup summaries and status writing; the author of a published test found the underlying data quality can vary, so treat its outputs as drafts rather than final answers.

Drafty — publishes any Claude-generated artifact (a page, a spec, a prototype) to a shareable drafty.im/canvas/… link with element-anchored comments. Reviewers click the exact element and leave a note without an account; the comment comes back to Claude through the CLI. Install: /plugin install drafty@claude-plugins-official.

What to check before enabling a plugin

The marketplace description tells you what a plugin claims to do. What matters more is what it actually runs. Before enabling:

Look at the component types. A plugin that only contains skills costs context only when you invoke a skill. A plugin that contains hooks or background monitors runs every session and adds to your system prompt — that cost is real, and it's why the plugin manager shows warnings for those types.

Read the README and check the GitHub repo. Stars and maintenance status matter. A plugin with 40 commits in the last month and an active issues page is more trustworthy than one with a polished description and a single commit from six months ago.

Disable what you don't use. Plugins are toggleable for a reason. If you only need a plugin for a specific project, /plugin disable name when you're not in that context. The context savings add up over a long session.

One finding from real testing: plugin UI quality doesn't predict data accuracy. A plugin that renders a polished HTML report can still surface numbers that are wrong. The flashy presentation and the reliable output are independent variables.

Hooks: the one that surprises people

Hooks are the most powerful component type and the one most people don't expect. A hook is an event handler — it fires at a specific point in Claude Code's workflow (after a file edit, after every tool call, before a commit) and can run any shell command.

The canonical use is a linter that runs after every Write/Edit tool call:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{ "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npm run lint:fix" }]
      }
    ]
  }
}

That's useful. The risk is enabling a plugin whose hooks you haven't read — they run commands on every matching event, silently, every session. The plugin manager surfaces a warning when a plugin includes hooks; take that warning literally and read the hooks/hooks.json before confirming.

Building your own plugin

You don't need to publish to a marketplace to use the plugin format. For a workflow you repeat across projects — a deployment script, a structured PR review, a brand voice check against your own guidelines — claude plugin init my-tool scaffolds the directory in ~/.claude/skills/my-tool/. It loads automatically as my-tool@skills-dir on the next session with no install step.

The structure is a SKILL.md in skills/<name>/ for each command, optional agents/ for custom agents, hooks/hooks.json for event handlers, and .mcp.json for MCP connections. Skills are just Markdown files with YAML frontmatter:

---
description: Review the current PR diff for correctness bugs and suggest fixes.
---
 
Review the git diff for bugs, then for simplifications. Report findings by severity.

One gotcha: skills in a plugin are namespaced. A skill called review in a plugin called my-tool is invoked as /my-tool:review, not /review. If you want the short name for personal use, put the file in .claude/commands/review.md instead.

Sharing a plugin output — the handoff that's still manual

Plugins are good at doing work inside Claude Code. The gap is the same one that shows up with Claude artifacts in general: once Claude produces something — a spec, a prototype, a report — getting useful feedback on it still requires a workflow outside the editor.

That's the loop: Claude Code plugins extend what Claude can do during the build; a review layer handles what happens when you hand the result to someone who isn't in Claude Code.