I keep a running count of plugins installed across my two machines. In January it was 34. Today it is nine.
Not because the rest were bad. Claude Code plugins, which started shipping in late 2025, now number more than 500 in Anthropic's marketplace alone, and most of them install and run without drama. They just don't earn the context they cost.
This list is not one person's taste test. Every pick was checked against four things: the plugin is listed in Anthropic's official marketplace, claude-plugins-official; it has a maintainer with a public track record; its install count is visible; and, where possible, an independent roundup names the same plugin. Install counts are from the marketplace listing in October 2026.
Seven of the nine are built by Anthropic. One is a third-party plugin that Anthropic lists, maintained by Jesse Vincent. The ninth is a wrapper I wrote around an MCP server, and I mark it as such.
What part of the evidence is missing
Three plugins below have no independent roundup citation: pr-review-toolkit, commit-commands, and plugin-dev. I looked and did not find one. They are in this list on the strength of the official listing and the code itself, which is a weaker claim, and I say so in each entry instead of inventing a citation.
That distinction matters. A list where all nine entries have identical-sounding praise is usually a list where the author checked nothing.
The test I use before keeping a plugin
Three questions, in this order.
- Does it change something on a normal Tuesday, not just during a demo?
- When it fails, does it fail loudly? A plugin that returns a confident empty answer is worse than no plugin.
- Does it add context I did not ask for? Every skill, agent, and command that Claude can invoke on its own puts its name and description in context on every turn, whether or not it runs.
Question three is the one I got wrong for a year. A plugin with twelve commands is not free. You pay for it in the window where your code lives. Anthropic now shows a context cost estimate on marketplace listings before you install, which is the number I wish I had checked earlier.
| Plugin | Maintainer | Installs (Oct 2026) | Also named by |
|---|---|---|---|
| frontend-design | Anthropic | 1,134,112 | Firecrawl skills list, Taskade skills list |
| superpowers | Jesse Vincent | 1,009,371 | Taskade (first pick), Firecrawl skills list |
| code-review | Anthropic | 438,525 | Firecrawl plugin roundup, Towards AI roundup |
| feature-dev | Anthropic | 256,017 | Towards AI (first pick), Medium plugin roundup |
| security-guidance | Anthropic | 241,800 | Towards AI roundup, Anthropic release notes |
| commit-commands | Anthropic | 171,244 | Anthropic plugin docs (used as the example) |
| pr-review-toolkit | Anthropic | 114,856 | no third-party citation found |
| plugin-dev | Anthropic | 67,663 | no third-party citation found |
Install counts measure adoption, not quality. Two plugins can do the same job and land 10x apart for reasons that have nothing to do with code. They are useful for filtering out abandoned work and for finding plugins other people already stress-tested.
Review and safety: three plugins that argue with me
code-review
You run /code-review on a PR branch. Several agents read the diff, each finding gets a confidence score, and the ones above your threshold get posted to GitHub. The threshold is configurable, and so is the focus: security, performance, accessibility.
It is the most recommended plugin of its type. Firecrawl's plugin roundup lists it under review tooling, and Towards AI puts it second of nine. Install count sits at 438,525, ahead of every other review plugin in the official marketplace.
That confidence scoring is why it survived here. Review plugins that flag everything get ignored by the third PR. Review plugins that flag eight things, six of them real, get read.
The failure mode I hit: on a 900-line migration diff it produced 40 comments, most of them style. I raised the threshold and stopped running it on diffs over 500 lines. The tool was fine. My input was bad.
security-guidance
This one runs on its own. No command to remember.
A fast pattern check intercepts Write, Edit, and MultiEdit before the change applies and warns on eight categories, including command injection in GitHub Actions workflows, unsafe child_process.exec calls, eval and new Function, XSS through innerHTML, and Python pickle deserialization. There is a model review at the end of each turn, and a deeper agentic review when you commit or push. Project rules go in .claude/claude-security-guidance.md.
Verification here is first-party rather than third-party: Anthropic shipped the plugin in May 2026 and wrote it up in its own week-22 release notes. Towards AI includes it third in its nine. Install count is 241,800, high for a plugin that adds no commands.
Warnings are session-scoped, so you see each one once and it does not nag. It still fires on test fixtures and deliberately bad example code. I keep an ignore path for tests/fixtures and move on.
The value is timing. Security advice in a wiki gets read once. A warning at the moment you type the vulnerable line gets read every time.
pr-review-toolkit
Six agents, each with a narrower job than "review this": comment accuracy, test coverage gaps, silent failures in error handling, type design, guideline compliance, and simplification.
No roundup I found cites it. What it has is 114,856 installs and six agents that each do one thing, which is the shape I prefer over a single generalist reviewer. Treat the missing citation as a caveat, not a dealbreaker.
The output is only as good as the diff you give it. I stopped using it on branches that mix a refactor with a feature, because the reviewers kept blaming the refactor for behavior the feature introduced.
The build loop: plan, commit, extend
feature-dev
Seven phases, three agents: an explorer that traces execution paths, an architect that proposes approaches with trade-offs, and a reviewer that checks the result against your conventions.
It is the top pick in Towards AI's nine-plugin list and appears in a Medium roundup from October as well. 256,017 installs. For once the consensus and my experience agree: the plan step is the whole point. When a model writes down which files it will touch and why, the number of surprise edits drops.
I use it for work that spans more than three files. For a one-file fix it is overhead.
commit-commands
/commit stages changes and writes a message that follows the repo's existing style. /commit-push-pr does the whole sequence. /clean_gone deletes local branches that no longer exist on the remote.
Its credibility signal is unusual: commit-commands@claude-plugins-official is the install ID Anthropic's own plugin documentation uses as its example. When the vendor reaches for your plugin to explain the system, that is a recommendation of a different kind. 171,244 installs.
Small thing, real time saved. I commit 15 to 20 times a day on a busy branch, and I was losing two or three minutes per commit to writing messages a script could draft. It also refuses to commit .env, which is the kind of guardrail you only notice when it saves you.
Needs gh authenticated for the PR step, and a remote origin configured.
plugin-dev
Seven skills covering hooks, MCP server integration, plugin structure, slash commands, agents, and skill authoring, plus twelve working examples and six validation scripts.
67,663 installs and no external roundup, which fits: it is for people who write plugins, not people who use them. If you have ever spent 40 minutes debugging why a hook did not fire because the file was named hook.json instead of hooks.json, it earns its slot.
Interface and workflow
frontend-design
The most-installed plugin in the marketplace at 1,134,112, and the one that most changes what a first draft looks like: type hierarchy, a restrained palette, real motion instead of a fade. Firecrawl and Taskade both include it in their skills lists.
It is a skill, not a command. It activates when you ask for interface work, which means it stays quiet in a backend repo but still sits in context. I disable it per-project for services.
It will not make a model a designer. It does move the first draft closer to something worth iterating on, which cuts a review round.
superpowers
A skills framework with a strong opinion: brainstorm before code, write a failing test before implementation, investigate root cause before fixing, and hand implementation to fresh subagents with a review after each task.
Taskade calls it the strongest skill to install first in 2026. Firecrawl lists it too. The 1,009,371 installs make it the second-most-installed plugin in the marketplace, and it is the only third-party plugin on this list that Anthropic distributes directly.
The planning discipline is what I use. On unfamiliar codebases it produces a short spec and a test skeleton before any implementation, and that alone has caught more bad assumptions than any prompt I have written. The cost is verbosity: some sessions produce more planning text than code. Worth it on a repo I inherited, excessive on one I wrote last month.
The other plugins I rotate in
A list of nine implies the marketplace stops there. It does not. A few verified alternatives that did not make the cut this quarter:
- code-simplifier, for cleaning up recently changed code without changing behavior
-
claude-md-management, for keeping
CLAUDE.mdcurrent instead of stale - Context7, for version-specific library docs
- Playwright, for browser automation and end-to-end checks
Each one is a real tool with real adoption. They just overlap with something I already have, and overlap is how a config turns into noise.
The ninth one is not a coding plugin, and that is why I kept it
Most plugin lists stop at developer ergonomics. The plugin that changed the most for me sits in a different category: it gives the agent access to live inventory instead of the model's memory of the world.
I build travel features. Before this, asking Claude for hotel options in a city produced names, star ratings, and prices that were plausible and often wrong. The model is not lying. It has no live rate feed, so it interpolates from training data.
This one is not in the marketplace. It is a wrapper I wrote, about forty lines of manifest and config, around an MCP server. The server is RollingGo Hotel MCP, which exposes hotel search, hotel detail with live room rates, and a tag list for filtering.
I am not going to pretend it has the same evidence base as the eight above. It is a small, young, vendor-maintained project: MIT licensed, 86 stars on GitHub, not in any roundup. What it has instead is a job no other plugin on this list does. The inventory claim is 2 million properties, 110,000 direct contracts, and it is free with no call cap.
The manifest is a small JSON file, and the server config lives in .mcp.json at the plugin root:
{
"mcpServers": {
"rollinggo-hotel": {
"type": "http",
"url": "https://mcp.rollinggo.ai/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
Then a normal prompt does the work:
Find three 4-star hotels near Shibuya Station for 2 nights starting 2026-11-14.
Show the cheapest room for each, the cancellation policy, and the total for two guests.
The agent calls searchHotels with the location and filters, then getHotelDetail for each candidate to pull room types and prices. What comes back is a real hotel ID, a live nightly rate, and a booking link, not a guess.
Two limitations I ran into, stated plainly:
- The API key version exposes three tools. The OAuth version adds order lookup and price confirmation, and requires business onboarding. If you need to complete a booking inside the agent, plan for that path.
- Rates move. A price shown at 9 a.m. can differ at 3 p.m. Any UI you build on top needs a re-check step before it shows a final number.
The config, install steps for Claude Code, Codex, and Cursor, and the full response schema are in the RollingGo Hotel MCP repository.
Installing the seven official ones
Marketplace install IDs follow the name@marketplace pattern. Claude Code adds the official marketplace on first run, so the IDs work without adding anything:
/plugin install code-review@claude-plugins-official
/plugin install security-guidance@claude-plugins-official
/plugin install feature-dev@claude-plugins-official
/plugin install commit-commands@claude-plugins-official
Superpowers installs the same way, or from its own marketplace if you want the bleeding edge:
/plugin install superpowers@claude-plugins-official
The five I deleted, and why
Naming specifics would start arguments, so here are the patterns.
The all-in-one mega bundle. Forty commands, six agents, and a skill for everything. Two thirds of it never fired, and the tool definitions alone ate context I needed for code.
The autonomous fixer. Point it at a failing test and it edits until green. It also edited the test. I spent an afternoon reviewing a "fix" that changed the assertion.
The duplicate. A plugin that wrapped a built-in behavior. It worked. It just added a second way to do the same thing, and I always picked the built-in one.
The unpinned plugin. No version, no changelog, force-updated on every install. It broke my hook config twice in a month.
The global hook. Installed a hook at user scope, ran on every project, and added 1.2 seconds to each edit. Measured it, removed it.
A quarterly audit that takes five minutes
Open /plugin and read the Installed tab. Newer versions group plugins under "Not used recently", which is a faster signal than my memory. Before installing anything, the same screen shows a context cost estimate.
# what is on disk right now
ls ~/.claude/plugins/
# turn one off without deleting it
claude plugin disable code-review
Two habits came out of that audit: install at project scope unless a plugin is truly universal, and read the plugin's files before reading its marketing page. Hooks and MCP configs are where surprises live.
FAQ
Do I need plugins at all?
No. Claude Code is useful with none. Plugins help when you repeat the same workflow weekly and want the steps to be consistent.
How many is too many?
There is no number, but there is a symptom: when the agent starts choosing the wrong tool for a request, you have too many similar tools loaded.
Are install counts a fair way to judge a plugin?
No. They show adoption, and adoption can come from a good launch rather than good code. They are useful for filtering out abandoned work and for finding plugins other people already stress-tested. Read the source before you trust anything.
Can a plugin contain an MCP server?
Yes. That is the pattern in the ninth entry above, and it is how most teams will ship domain-specific capabilities to coding agents. Anthropic's docs cover the .mcp.json layout.
Six of the nine are conveniences, two change how carefully I work, and one removes a category of wrong answers. If you only try one thing from this post, try giving your agent a live data source for the domain it keeps guessing about.
Top comments (0)