Claude Code Plugins: What I Kept, What I Deleted (2026)

Quick Answer (2026): Claude Code plugins are self-contained directories that bundle skills, subagents, hooks, MCP servers, and language servers, so you install a whole workflow with one command instead of copying loose files into .claude/. After three weeks running them on real work in 2026, the ones worth keeping were the per-language LSP plugins and security-guidance. The ones I deleted were integration plugins I never actually called, because every enabled plugin adds tokens to your context on every turn. Install a language server plugin for each language you truly touch, read the "Will install" panel before you say yes, and check the "Not used recently" list once a month.

I typed /plugin for the first time and got a little embarrassed.

There were four tabs and a marketplace I did not remember adding. There were plugins I had installed weeks ago, on a whim, still loading on every session. One of them I had used exactly once.

So I did the boring thing. I ran plugins on a real Next.js and Postgres side project and a TypeScript CLI at work for three weeks, kept a log, and then went back and deleted. Here is what stuck.

What a Claude Code plugin actually is

A plugin is a self-contained directory of components that extends Claude Code. Per the Claude Code plugin docs (2026), the components are the exact primitives you already know: skills, subagents, hooks, MCP servers, and LSP (language server) servers, plus background monitors.

That reframe is the whole point of this post.

I have field-logged those pieces one at a time before, skills and the MCP servers I keep installed. A plugin does not add a new power. It adds a packaging layer over the primitives, with a .claude-plugin/plugin.json manifest, a version, and namespacing so a plugin's skill shows up as /plugin-name:skill-name instead of colliding with yours.

So the real question is not "what can plugins do." The docs answer that. The question is whether the packaging changes how I work. Sometimes yes. Often no.

The setup is two steps, not one

You add a marketplace, then you install from it.

The official Anthropic marketplace, claude-plugins-official, registers itself the first time you launch Claude Code interactively. If it did not, you add it by hand:

/plugin marketplace add anthropics/claude-plugins-official
/plugin install github@claude-plugins-official

The community marketplace is separate and manual. You add anthropics/claude-plugins-community and install from it as @claude-community. Every install asks for a scope: user (you, everywhere), project (everyone on the repo, written into .claude/settings.json), or local (you, this repo only).

Small gotcha I hit: after some installs Claude Code prints Run /reload-plugins to activate. and nothing happens until you do. If the reload wants to re-read the conversation, it warns and waits for /reload-plugins --force.

What I kept after three weeks

The LSP plugins were the biggest single quality jump, and it is not close. Installing typescript-lsp (and pyright-lsp on the Python side) gives Claude real diagnostics after every edit. It sees the type error I just introduced and fixes it in the same turn, instead of me finding it three prompts later when the build breaks. You still install the actual language server binary yourself; the plugin only wires it in.

security-guidance stayed too. It reviews each change for common vulnerabilities and tells Claude to fix what it finds before moving on. Cheap insurance on anything touching auth or SQL.

commit-commands earned its spot on the work repo. It bundles the git commit, push, and PR flow into one skill, and it is the one integration-flavored plugin I reach for daily. The github integration plugin, which bundles a preconfigured MCP server, I kept only on the repo where I actually open PRs from the terminal.

That is four plugins. The Reddit thread cataloguing the 50+ official Claude Code plugins lands on almost the same short list: typescript-lsp, security-guidance, and a couple of MCP servers. When a "what do you actually run" thread and my own three-week log agree, that is the signal.

What I deleted, and why

The integration plugins I never called. I had installed a project-management MCP integration during a spike, used it twice, and then it sat there loading its tools into context on every session for two weeks.

Claude Code eventually told on me. The /plugin Installed tab now groups plugins you have not used in at least two weeks over at least ten sessions under a Not used recently header, with a Last used line on each. Three of mine were sitting there. I uninstalled all three.

The output-style plugins (explanatory-output-style, learning-output-style) went too. Fun for a day, noise after that.

The cost nobody in the roundups prices

Every enabled plugin is not free. It costs context.

Open a plugin's detail pane and Claude Code shows a Context cost estimate: the tokens that plugin adds to your window on every turn. It also shows a "Will install" list of the exact commands, skills, agents, hooks, and MCP and LSP servers it brings.

MCP-bundle plugins are the worst offenders. Enabling one can invalidate the prompt cache, which forces the next request to re-read the whole conversation. That is why /reload-plugins sometimes warns and refuses until you pass --force. Tool search helps by deferring MCP tools, but the default is: more plugins, heavier context, slower turns.

So plugin sprawl is a real tax, not a vibe. The "Not used recently" header exists because Anthropic knows people over-install and forget.

One more thing the "best plugins" lists skip: the trust surface. Plugins and marketplaces run arbitrary code on your machine with your privileges, and Anthropic does not vet the MCP servers a community plugin bundles. I now treat a plugin install like adding a dependency to package.json. I read the "Will install" pane, I check the source, and only then do I say yes.

When a plugin beats a plain .claude/ file

If it is just for me, on one project, I keep it as a loose file in .claude/. Faster to edit, nothing to package.

I convert to a plugin when I want to share it. That is the honest line the docs draw too: standalone for personal and quick, a plugin for versioned, namespaced, team-installable. The migration is a cp of your commands/, agents/, and skills/ folders into a plugin directory plus a manifest.

My routing rule for plugins in 2026

Install an LSP plugin for every language you actually touch. That is the highest-value install by a wide margin.

Keep security-guidance on. Keep one workflow plugin you use daily, like commit-commands.

Be ruthless about MCP-bundle integrations: install one only when you use that service from the terminal, and delete it the moment it shows up under "Not used recently." Read the "Will install" pane every time.

If skills stop appearing after all that, clear the cache with rm -rf ~/.claude/plugins/cache and reinstall. That fixed it twice for me this month.

Plugins did not change what Claude Code can do. They changed how much of it I carry around. The win was not installing more. It was deleting four.

P.S. The plugin I used exactly once is gone. I feel lighter already.