Claude Code Plugins: Inside Anthropic's Official Directory (2026 Guide)

Anthropic shipped the official Claude Code plugin directory on May 22, 2026. Four days later, the anthropics/claude-plugins-official repo has crossed 20,000 stars and the /plugin panel ships out-of-the-box with a curated catalog you can browse from inside Claude Code.

If you've been running Claude Code daily, this is the biggest workflow change since Skills shipped in 2025. The plugin system has technically been around since October 2025 as a public beta — but until last week, the discovery story was "go scroll a community marketplace and hope it's safe to install." Now there's a vetted directory of 55+ plugins maintained by Anthropic, alongside a community marketplace of 70+ more that have passed automated safety screening.

This post is the operator's-eye walkthrough: what plugins actually are, what's in the directory, how to install one, the handful I'm running across my daily setup, and how to build your own when nothing in the catalog fits.

What a plugin actually is

A Claude Code plugin is a single installable package that can bundle any combination of:

• Skills — model-invoked capabilities Claude reaches for automatically based on context
• Subagents — specialized agents Claude can delegate to so the main conversation's context stays clean
• Slash commands — user-invoked commands you type
• Hooks — scripts that run on Claude Code events (PreToolUse, PostToolUse, SessionStart, etc.)
• MCP servers — preconfigured Model Context Protocol connections to external services
• LSP servers — Language Server Protocol integrations for code intelligence

Before plugins, you wired all of this up by hand. You'd add an MCP server config to ~/.claude/.mcp.json, drop a slash command into ~/.claude/commands/, set up hooks in settings.json, install a Skill somewhere your Claude session could see it. Sharing any of it with a teammate meant a copy-paste safari across four different config files.

A plugin collapses that to one install command. The package author bundles the pieces, you run /plugin install <name>, and Claude Code wires everything up at the right scope (user, project, or local).

The other thing to internalize: plugins are distributed via git. A marketplace is a git repo containing a .claude-plugin/marketplace.json manifest plus the plugin payloads. That means anything you can host on GitHub, GitLab, Bitbucket, or even a private self-hosted git server can be a plugin marketplace. Anthropic's official directory is just the most curated one.

The two marketplaces you should know about

Out of the box, Claude Code (v2.1.143 and later) comes with the official Anthropic marketplace pre-configured. You can browse it immediately by running /plugin and tabbing to the Discover screen.

The two marketplaces worth knowing:

claude-plugins-official — auto-available. Curated by Anthropic. Inclusion is at their discretion. This is the place to start.

anthropics/claude-plugins-community — manual add. Third-party plugins that have passed Anthropic's automated validation and safety screening. Each plugin is pinned to a specific commit SHA. Wider catalog, more long-tail use cases, less curated.

To add the community marketplace:

/plugin marketplace add anthropics/claude-plugins-community

Then install from it using the claude-community marketplace suffix:

/plugin install <plugin-name>@claude-community

You can also point Claude at any third-party marketplace via GitHub owner/repo shorthand, a git URL, a local path, or a remote marketplace.json URL. We'll come back to that.

What's actually in the official directory

The Anthropic-maintained catalog breaks down into five rough categories.

Code intelligence (LSP plugins)

This is the category that quietly changes the most about how Claude Code feels day-to-day. Once you install the LSP plugin for the language you're working in, Claude gets two new abilities the second it edits a file:

1. Automatic diagnostics — after every edit, the language server reports back type errors, missing imports, and syntax issues. Claude sees them in the same turn and fixes them without you saying anything. No "run the linter and tell me what broke" round-trips.
2. Real code navigation — jump to definition, find references, hover for type info, list symbols, trace call hierarchies. Much more precise than grep-based search.

The official directory ships LSP plugins for eleven languages:

The plugin won't install the binary for you — you bring that — but once the binary is on your $PATH, the plugin handles the rest of the wiring. If you write TypeScript daily and you haven't installed typescript-lsp yet, do that today. It's the single highest-leverage plugin in the directory.

External integrations (preconfigured MCP servers)

These plugins bundle an MCP server config so you can connect Claude to a real service without writing a line of JSON.

• Source control: github, gitlab
• Project management: atlassian (Jira + Confluence), asana, linear, notion
• Design: figma
• Infrastructure: vercel, firebase, supabase
• Communication: slack
• Monitoring: sentry

A year ago, plugging Claude into your Linear or your GitHub took fifteen minutes of MCP-server-config debugging. Now it's /plugin install linear@claude-plugins-official and you're done. The auth prompt fires the first time you ask Claude to read a ticket.

Automatic security review

The security-guidance plugin reviews each change Claude makes for common vulnerabilities and instructs Claude to fix what it finds in the same session. If you're an operator shipping production code with Claude — and especially if you're not personally reviewing every diff — this is non-negotiable. Install it.

Development workflows

Skills + agents bundled for common dev tasks:

• commit-commands — Git commit workflows including commit, push, and PR creation
• pr-review-toolkit — Specialized agents for reviewing pull requests
• agent-sdk-dev — Tools for building with the Claude Agent SDK
• plugin-dev — Toolkit for creating your own plugins

commit-commands is the one I'd install first. The skill writes commit messages from your staged diff, runs the commit, optionally pushes, optionally opens the PR. The output is namespaced as /commit-commands:commit, so you invoke it explicitly and you always know what's running.

Output styles

• explanatory-output-style — Claude adds educational asides about implementation choices as it goes
• learning-output-style — interactive learning mode, pauses for you to predict outcomes before showing them

Useful when you're onboarding to an unfamiliar stack and want Claude to teach as it builds, rather than producing code you can't fully explain after the session ends.

Installing your first plugin (concretely)

The fastest path. From inside Claude Code:

/plugin install commit-commands@claude-plugins-official

If you'd rather browse, type /plugin to open the manager. You'll see four tabs you cycle through with Tab:

• Discover — browse plugins from every marketplace you've added
• Installed — view, enable, disable, or uninstall what you have
• Marketplaces — add, remove, refresh
• Errors — see what failed to load

On a plugin's detail pane (v2.1.143 and later) you'll see three things worth checking before you install:

• Context cost — how many tokens the plugin adds to your context window every turn
• Last updated — when it shipped its most recent change
• Will install — exactly which commands, agents, skills, hooks, and MCP/LSP servers the plugin adds

That Will install section is the one to read. A plugin can quietly drop a Skill that activates on every session — fine if you trust the author, less fine if you don't. Read it before you click.

Then pick a scope:

• User scope (default) — installed for you, across every project
• Project scope — installed for everyone collaborating on this repo (adds to .claude/settings.json, gets committed)
• Local scope — installed for you, only in this repo

User scope is the right default for personal tools (commit-commands, your LSP). Project scope is the right default for anything the whole team should run identically (security-guidance, a team-specific MCP integration). Don't mix them up — a project-scoped install on a public open-source repo will prompt every contributor.

After installing, run /reload-plugins to pick up the change without restarting. Then invoke a skill the plugin provides:

/commit-commands:commit

Plugin skills are always namespaced by plugin name, so there's never a collision with your own slash commands.

The plugins I'm running daily

For context, I run Claude Code across a portfolio of products — iOS apps, Next.js marketing sites, a Python trading bot, and a 24/7 always-on operator setup that spans desktop, mobile, and remote. Here's the actual rotation in user scope as of today:

• typescript-lsp — installed everywhere. The post-edit diagnostics loop alone has cut my "fix the type errors Claude introduced" turns by something like 80%.
• swift-lsp — installed for the iOS work. Same story but for SnowFire and the partner-distributed iOS apps in development.
• pyright-lsp — installed for the trading bot.
• commit-commands — installed user scope. Replaces the bespoke /commit slash command I'd been carrying around in ~/.claude/commands/.
• security-guidance — installed project scope on every public-facing product (the marketing sites, claudecamp.ai itself).
• github — installed user scope so any session can read PRs and issues without me re-wiring MCP per repo.
• vercel — same, for deploys and logs across the portfolio.
• sentry — installed project scope on the products that have Sentry, so production-investigation conversations have it available immediately.

Two I haven't installed and probably won't, in case it saves you the cycle: the output-style plugins. I want Claude's responses lean and operator-grade by default; the explanatory style is great for teaching, less great when you're shipping eight things in parallel.

When the catalog doesn't fit: build your own

A meaningful share of plugin value comes from packages that don't (and shouldn't) live in the official directory — the team-specific MCP integration that wraps your internal API, the slash commands that encode your team's deploy choreography, the hooks that enforce your repo's commit conventions.

A plugin marketplace is just a git repo with a .claude-plugin/marketplace.json manifest at the root. The structure is:

your-marketplace/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    ├── plugin-one/
    │   ├── plugin.json
    │   ├── skills/
    │   ├── commands/
    │   ├── agents/
    │   ├── hooks/
    │   └── mcp.json
    └── plugin-two/
        └── ...

Once it's a git repo, you (or anyone you share it with) installs it with:

/plugin marketplace add your-org/your-marketplace

Then /plugin install plugin-one@your-marketplace does the rest.

For team adoption without each member having to add the marketplace by hand, drop the marketplace into your project's .claude/settings.json as a known marketplace:

{
  "extraKnownMarketplaces": {
    "my-team-tools": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins"
      }
    }
  }
}

When a teammate trusts the repo folder for the first time, Claude Code prompts them to install. Same upgrade story as the official marketplace — opt-in, not surprise-on-launch.

The plugin-dev plugin in the official directory ships scaffolding and validators for new plugins. Start there; don't write the manifest from scratch.

The security note that actually matters

Plugins execute arbitrary code on your machine with your user privileges. Anthropic's automated screening on the community marketplace catches obvious abuse but isn't a substitute for trust.

Three rules I follow:

1. Default to the official marketplace. Curated, audited, the lowest-risk place to start.
2. Read the Will install pane before installing. If a plugin claims it just adds a slash command and the pane shows hooks + an MCP server + four skills, that's worth understanding before you say yes.
3. For team-scoped installs, the marketplace source belongs in a private, owned repo. Don't pin team workflows to a community plugin that might disappear or change ownership.

For everything else — your personal LSP plugins, the GitHub integration, commit-commands — the official directory is the floor of trust and you can move fast inside it.

What this changes about Claude Code operations

A year ago, running Claude Code "the way Kev does day-to-day" meant carrying a personal .claude/ folder around between machines, hand-syncing MCP configs, copy-pasting hooks. The plugin system already started collapsing that. The official directory finishes the job: the operator-grade setup is now an opinionated install list, not a configuration sport.

If you're running Claude Code casually and you haven't touched /plugin yet, set aside thirty minutes:

1. Install the LSP plugin for your primary language.
2. Install commit-commands at user scope.
3. Install security-guidance at project scope on whatever you're shipping next.
4. Install the MCP plugin for whatever external service you spend the most time clicking around in (GitHub, Linear, Vercel, Sentry — pick the one).

That's the baseline. Everything else compounds from there.

If you're running Claude Code already and you want the rest of the operator stack — Skills you write yourself, the always-on mobile + remote setup, Routines wired to real triggers, the Agent SDK and Managed Agents at the level where you can direct or hire any agentic build — that's the 2-day Intensive. Live, hands-on, building one real project together. No prior Claude experience required.