Stop Installing Every Claude Code Plugin — Here's How to Tell What's Actually Worth It
I tested 11 plugins, fixed broken marketplace files, and built a judgment framework. This is what I'd keep, skip, and watch.
Claude Code plugins can look like a blur of skills, commands, MCPs, and marketplaces if you use AI regularly but have not gone deep into the ecosystem. This guide sorts out what these layers are, which plugins are worth your attention, what broke when I tested them, and how to judge whether they fit your own work.
Claude Code’s plugin marketplace launched quietly. Soon it wasn’t quiet anymore.
Developers started running Claude skills on every session. Marketers installed business plugins and expected them to know their business. Builders stacked MCP servers on top of hooks on top of skills and wondered why things felt slow.
The biggest frustration was never whether plugins work.
It’s that it’s almost impossible to tell what “working” actually means until you’ve run one on something real.
I’ve been building and shipping with Claude Code daily since it launched. When the plugin ecosystem expanded to 101 official plugins, I decided to stop guessing and start testing. I ran content plugins on my actual writing system. Business plugins on my actual positioning questions. Coding plugins on a real feature build for an app I maintain.
For the same real-work test applied to the tools themselves — not the plugins — the 8-tool AI coding audit runs Claude Code, Cursor, and six others through the same three-stage evaluation approach.
Here’s what I’m going to show you: what Claude Code plugins actually are (the building blocks most people mix up), what changed when I ran them on real work, where things broke, and the scorecard you can use to judge any plugin before it earns a place in your stack.
11 plugins tested. 4 worth keeping always. 5 worth enabling in the right session. 2 that weren’t worth it. And a few that just don’t belong in certain workflows at all.
Hi, I’m Jenny 👋
I teach non-technical people how to vibe code complete products and launch successfully. AI builder behind VibeCoding.Builders and other products with hundreds of paying customers. See all my launches →
If you’re new to Build to Launch, welcome! A few related reads that pair well with this one:
Table of Contents
What Claude Code Plugins Actually Are
People use “plugin” to mean several different things inside Claude. They do not behave the same way. Once you see the building blocks, the confusion disappears.
The four building blocks people keep mixing up
A Claude Code plugin bundles one or more of these:
Skills — what most people mean by “using a plugin.” You trigger them with a slash command (
/brand-voice:enforce-voice,/marketing:seo-audit). Runs once, does its job, stops. Cost: per use.Hooks — run automatically in the background. They attach to events (file write, session start, commit) and fire every time without you asking. Cost: every session they are active.
Commands — the management layer.
/plugin install,/plugin disable,/plugin marketplace add. Free. Not the plugin itself.MCP servers — external connections to databases, APIs, file systems. Not plugins themselves, but bundled inside plugins so often that people treat them interchangeably. Cost: per query. (For a specific setup walkthrough, connecting Gmail across multiple accounts via MCP shows the exact installation pattern.)
Why it feels muddy: one plugin can contain skills, hooks, and MCP configs together. You install one thing, you get three behaviors at three cost levels. That matters when you ask “why is this session slow?” or “why did something run that I did not ask for?”
For how the skills layer specifically compares to ChatGPT GPTs and Gemini Gems — same general idea, meaningfully different architecture — Claude Skills vs. ChatGPT GPTs and Gemini Gems is the side-by-side.
For a full walkthrough with screenshots, see How to Onboard to Claude Without the Learning Curve. This article picks up where that one left off.
Claude Code plugins versus Claude plugins
Three products. Different installation. Different capabilities.
Claude web (claude.ai) — MCPs, web search, built-in tools. No terminal, no local file access, no hooks, no slash-command plugin system.
Claude Desktop — MCP-based extensions for file access, database queries, APIs, browser tools. More capable, but still not the Claude Code plugin layer.
Claude Code — the full system. Skills, hooks, commands, MCP servers, marketplace browsing, always-on vs. triggerable behavior, local file access.
You install through the CLI:
/plugin install security-guidance@claude-plugins-official
/plugin marketplace add owner/repo
/plugin install brand-voice@knowledge-work-plugins
Plugins live in ~/.claude/plugins/ and work across projects once installed globally. The confusion starts here: someone reads about a Claude Code plugin, looks for it in Claude Web, cannot find it. Same brand name, different product.
Where plugins come from
Three levels. The trust story is different at each one.
Level 1: Official Anthropic marketplace
claude-plugins-official is built into Claude Code. As of March 2026: 101 plugins (browse here).
33 Anthropic-built: language servers (12), dev workflow (10, including
feature-dev,code-review,commit-commands,security-guidance,frontend-design), setup tools (5), output styles (2), playground (1), messaging (3)68 partner plugins: GitHub, Playwright, Supabase, Figma, Vercel, Linear, Sentry, Stripe, Firebase, and more
Two additional Anthropic marketplaces (require manual add):
life-sciences — 17 biomedical plugins
knowledge-work-plugins — 14 role-based plugins (Sales, Marketing, Finance, Legal, HR, Brand Voice)
There are also 11 plugins tagged “Cowork” on claude.com/plugins. The site labels them Cowork-only. Misleading. I installed and tested Brand Voice, Marketing, Sales, Productivity, and Cowork Plugin Management directly in Claude Code through knowledge-work-plugins. They work.
Level 2: Community marketplaces
GitHub repos anyone can share. Add with /plugin marketplace add owner/repo. No verification. Quality depends on the maintainer.
Worth knowing:
ComposioHQ/awesome-claude-plugins— 25-30 production pluginsjeremylongshore/claude-code-plugins-plus-skills— 346 plugins, quality-gradedalirezarezvani/claude-skills— 192+ plugins
Not everything in these repos is installable. Some have full plugin.json packages. Others are standalone skill files for .claude/skills/. “1,916 skills” does not mean 1,916 things you can /plugin install.
Level 3: Discovery tools
Sites you will hit before finding the official marketplace:
ClaudePluginHub.com — 14,083+ indexed
Build with Claude — 2,865 marketplaces
claude-plugins.dev — community registry
These are search engines, not sources. They scan GitHub for plugin.json and index what they find. Useful if you know how to evaluate. If not, stick with official repos.
From Anthropic’s docs: “Plugins and marketplaces are highly trusted components that can execute arbitrary code on your machine. Only install from sources you trust.”
Private or team plugins sit outside all three levels. Custom builds from a local path or hosted source.
The Plugins I Tested
I tested in four buckets: content, business, coding, and one niche life sciences case. For each plugin, three questions:
Where does it work?
Where does it break?
Does it earn a place in the stack?
Then I used those tests to answer the bigger questions underneath: workflow fit, overlap, collaboration, and whether the plugin was improving my process or just adding machinery.
Content plugins
The easiest to evaluate. I could run them against my real content engine, Substack workflow, and brand materials.
How to install the plugins in this section:
# What I actually used during testing
/plugin marketplace add /Users/bouyang/Documents/Zxperiment/media/newsletter_position/knowledge-work-plugins
/plugin install brand-voice@knowledge-work-plugins
# Official plugin in this section
/plugin install explanatory-output-style@claude-plugins-official
Note: knowledge-work-plugins had schema validation issues during testing. I used a local fixed copy. That breakage matters and I come back to it later.
Plugin 1: Brand Voice
What it is: Three-skill plugin. Discovers your scattered brand materials, generates guidelines, enforces your voice.
/brand-voice:discover-brand— searches directories, platforms, and products for brand materials/brand-voice:generate-guidelines— synthesizes into a structured guidelines file/brand-voice:enforce-voice— applies guidelines as you write
Where it works: Most creators have brand guidelines in five places: a Notion doc from 2023, a Google Doc nobody reads, random files in a content folder. This plugin finds all of it and makes it usable.
On my content-engine directory:
Found 15 brand documents across subdirectories
Found 34 Gumroad products I had never reviewed for consistency
Generated a 963-line guidelines file saved to
.claude/brand-voice-guidelines.mdAvailable automatically in future sessions
The output difference was immediate.
Without Brand Voice:
“In this comprehensive guide, we’ll explore the landscape of Claude Code plugins. It’s worth noting that the plugin ecosystem has grown significantly.”
With Brand Voice enforced:
“Claude Code has 30 official plugins. I had one installed. It came from a life sciences template I’d forgotten about.”
Where it breaks: If you create content for different channels with different voices, leaving it on globally steers everything toward one guideline set. That can work against you.
Verdict: KEEP. One-time discovery + guidelines generation pays back on every article after.
For the visual side of the same content workflow — generating hero images, infographics, and carousels — Nano Banana 2 in Claude Code tests 7 creator workflows on 100+ real outputs, the same way this article tests plugins.
The bigger question it raised:
If I already have a voice, or write across multiple channels, when does a plugin like this genuinely help and when does it start steering work in the wrong direction?
Plugin 2: explanatory-output-style
What it is: Always-on hook. Modifies every Claude response: progressive disclosure, layered explanations, insight sections, teaching scaffolding.
Where it works: I asked Claude to explain the plugin marketplace system. Output was 9/10 for clarity: three-layer architecture walkthrough, component deep dives, ASCII flow diagrams, progressive disclosure from simple to advanced. For tutorial writing and technical explainers, this is exactly the structure you want.
Where it breaks: It is a hook, not a skill. It runs on every response.
Quick coding question? Still gets a structured lesson.
Content editing? Still gets a structured lesson.
Adds token cost to every exchange, not just the ones where structure helps.
Verdict: CONDITIONAL KEEP. Strong for tutorials and documentation. Too much for everything else.
The question it left:
When is always-on structure worth the session cost, and when does it become drag?
Business plugins
This is where I hit the difference between polished output and trustworthy output.
How to install the plugins in this section:
# What I actually used during testing
/plugin marketplace add /Users/bouyang/Documents/Zxperiment/media/newsletter_position/knowledge-work-plugins
/plugin install marketing@knowledge-work-plugins
/plugin install sales@knowledge-work-plugins
/plugin install productivity@knowledge-work-plugins
Plugin 3: Marketing
What it is: Six-skill plugin for the full content marketing workflow: SEO audit, drafting, brand review, competitive research, campaign planning, email sequences.
Skills tested: /marketing:seo-audit, /marketing:draft-content, /marketing:brand-review, /marketing:competitive-brief
Where it works: Each skill is useful alone. Together they chain: audit finds gaps, drafting fills them, review catches compliance issues.
I tested three parts across ~1 hour 40 minutes:
SEO audit (30 min) — full audit of buildtolaunch.com. 25 keyword opportunities, 7 competitors benchmarked, 90-day action plan.
Content drafting (45 min) — three SEO-driven drafts (~2,900, 4,100, 3,600 words) with Brand Voice applied.
Brand review (25 min) — 4 high-priority issues caught: missing personal intros, uncited revenue claims, affiliate disclosure gaps. Compliance score: 85/100.
Where it breaks: Drafts still needed editing. Not publish-ready. But they were real working drafts with structure and voice applied, not throwaway copy.
Verdict: KEEP. Enable for content planning sessions. Disable for Notes and quick social posts.
The question it raised:
How do you tell when a plugin is working with another plugin versus just running beside it?
Plugin 4: Sales
What it is: Ten-skill plugin for sales workflows: competitive intelligence, pipeline review, cold outreach, call prep, forecasting, account research.
I ran /competitive-intelligence on Build to Launch. The HTML battlecard looked finished: tabs, comparison matrix, dark theme, talk tracks, landmine questions per competitor. Generated in 2 minutes.
Then I read the data.
Claimed I had 2,000 subscribers. I have 5,000+.
Compared me to The Rundown AI (2M subscribers) and DeepLearning.AI (7M learners). Completely different league.
The analysis was no better than asking Claude Code without any plugin.
The real problem: Marketing has a competitive-brief skill covering similar ground. I ran both on the same question: who are my competitors and where am I positioned?
Sales — flashy output, wrong data, wrong tier.
Marketing (~45 min) — 3 comparable competitors identified, “stuck-in-the-middle builder” positioning gap found, 10+ content gap opportunities, 7 actions split into quick wins and strategic moves. Grounded in my actual tier.
Most of the Sales plugin is designed for professionals with CRM pipelines and regular customer calls. If that is not your setup, most of its surface area sits unused.
Verdict: SKIP for content creators and builders. The overlap with Marketing is real. When both answered the same question, Marketing was more accurate and more useful.
The bigger question:
When a plugin looks good on paper, how do you tell whether it is for you or for a completely different operator?
Plugin 5: Productivity
What it is: Task management and daily planning. /start creates structured breakdowns, priority rankings, persistent memory across sessions.
Where it works: Thoughtful design. Project-based organization, priority ranking, file-based persistence. If you have no task system, this is a reasonable place to start.
Where it breaks: If you already use Notion, Linear, a custom panel, or even a well-maintained markdown file, this adds another layer managing the same information. I tested /start, confirmed it works, and moved on.
Verdict: SKIP if you have a working system. Try it if you have nothing.
💎 Up to this point, you’ve seen the individual tests.
What changed my mind was not any single plugin result. It was the bigger questions those tests kept raising:
When does a plugin genuinely improve the way you already work, and when does it just add another layer?
When do two plugins actually collaborate well?
When do they quietly overlap and start cannibalizing each other?
When is an always-on plugin worth the extra cost and friction?
And after testing all of this, what stack would I actually keep?
The next part of this article covers those.
I’ll start with the first three questions, then move into the coding plugins I tested on a real build, and close with the cost logic, the stack I’d actually keep.
Towards the end, you’ll get the two quick-reference methods I would use to judge any new plugin.