The first plugin I installed in Claude Code did something I had been doing by hand for nine months.
It was a skill called frontend-design. I added it, asked Claude to build a landing page, and watched it ignore every default React-and-Tailwind cliché it usually reaches for. No emoji buttons. No space-y-4 p-6 rounded-2xl. No three-column-card grid. The skill loaded in a specific design vocabulary at the top of the turn and pushed the rest of the model output into a different aesthetic universe. I had been writing that vocabulary into my own system prompt for nearly a year. Now it was a one-line install.
That was the moment I understood what the Claude Code plugin marketplace actually is. It is not an app store. It is a distribution system for opinions. Specifically, the opinions about how to do a thing that you used to keep in your own CLAUDE.md, in a Notion page, or in your head. The marketplace turned those opinions into installable units that any developer can subscribe to in thirty seconds.
By May 2026, the official marketplace lists hundreds of plugins, the community marketplaces have shipped over two thousand skills, and the ergonomics finally feel like a real ecosystem rather than a hobby project. This is the post I wish I had read in February when I was still confusing plugins, skills, MCP servers, and hooks and reaching for the wrong one on every problem.
The Mental Model
The single sentence that unlocks the marketplace is this. Plugins are the distribution format. Skills are the content. MCP servers are the data layer. Hooks are the automation.
If you only remember one paragraph from this post, remember the four nouns and what each of them does.
A skill is a Markdown file with a SKILL.md at its root, optional supporting files, and a frontmatter block that tells Claude when to fire. A skill teaches the model how to do a specific thing well: write Remotion videos, debug a flaky test, audit SEO, review React components, build a landing page in a specific style. When the user's request matches the skill's trigger description, Claude reads the skill and follows its instructions. The model does not run anything outside its normal toolset. The skill is, fundamentally, structured prompt material.
A plugin is a packaged folder that can contain one or more skills, plus MCP server configs, hooks, slash commands, and agent definitions. It is the unit you install and uninstall. Plugins are how skills travel between developers. The Anthropic-official marketplace ships plugins. The community marketplaces ship plugins. Your team's private GitHub repo ships plugins. The wrapper is always the same.
An MCP server is a separate process that exposes tools to the model over a standardised protocol. If you want Claude to read your Linear tickets, query your Postgres, or look up your internal Confluence, you need an MCP server for that data source. The marketplace lists MCP servers as plugin components. Installing them wires the model into real systems. I went deep into MCP in the MCP developer guide; the short version is that MCP is the thing that turns Claude from "a model that writes code" into "an agent that touches your stack."
A hook is a shell command the harness runs in response to lifecycle events. SessionStart, UserPromptSubmit, Stop, PostToolUse, etc. Hooks are not prompts. They are real automation. They run when something happens, regardless of what the model thinks. Hooks are how plugins enforce behavior the model cannot enforce on its own. You can find the full event list in the Claude Code hooks docs.
Most plugins use two or three of these primitives. A well-designed plugin uses all four. The shape of a great plugin is something like: skills for the agent's behavior, MCP servers for the data the skills need, hooks to enforce the rules the skills suggest, and slash commands to expose the most common workflows to the user.
Once you see the four pieces, every plugin you read becomes legible.
What The Marketplace Actually Looks Like
The default Anthropic marketplace ships with every Claude Code install. You did not have to do anything to get it. Run /plugin list inside Claude Code and you will see plugins from anthropics/claude-plugins-official. The official set is conservative: code review, security review, status line config, a few language-specific best practices, the init plugin that drops a CLAUDE.md template.
The much larger world lives in community marketplaces. The biggest catalogues I have used.
The claudemarketplaces.com directory is a discovery surface, not a marketplace itself. It indexes plugins from GitHub and lets you search by category, popularity, and last update. Useful for browsing. It does not host. The install command still points at the source repo.
The tonsofskills.com project bundles 425 plugins and 2,810 skills with a ccpi CLI on top. The CLI is closer to npm than to apt: search, install, version-pin, dependency-resolve. It is the closest thing the ecosystem has to a real package manager. It is also community-curated, which means the quality bar is wide. Some skills are excellent. Some are someone's lunch break.
The Vercel plugin marketplace, which ships as part of the Vercel CLI, is a vertical bundle. It includes deployment helpers, AI Gateway routing, Vercel Sandbox tooling, the bootstrap orchestration, and a handful of MCP servers for project metadata. If you ship to Vercel, this is the one to add first.
There are smaller domain-specific marketplaces. One for security tooling, one for Notion automation, one for video creation around Remotion, one for the Anthropic API itself. They each ship a couple of dozen plugins, deep on their vertical, shallow on everything else. Pick the ones that match your stack and skip the rest.
The pattern across all of them is the same. A marketplace is a Git repo with a marketplace.json at the root, listing the plugins it hosts. You subscribe to the marketplace once. New plugins inside it become discoverable automatically. Updates to existing plugins flow through on the next update. Removing the marketplace removes everything you installed from it.
This is a deliberate design call from Anthropic, and it is the right one. The fragility of an "app store" model is that one central registry becomes a chokepoint. The Git-repo-as-marketplace model means anyone can run one, anyone can fork one, and the cost of running your own is roughly the cost of a public GitHub repo.
How To Actually Install Things
There are three install workflows in 2026, depending on where the plugin lives.
The first is the official marketplace, already attached to your install. To install a plugin from it:
/plugin install code-reviewer
That is the whole command. The plugin downloads, the harness picks up the new skills and slash commands, and you can use them in the same session. No restart.
The second is community marketplaces hosted on GitHub. You add the marketplace once.
/plugin marketplace add tonsofskills/marketplace
After the marketplace is added, every plugin it contains is installable by name.
/plugin install tonsofskills/seo-audit
/plugin install tonsofskills/frontend-design
The harness pulls the plugin from the source repo, validates it, and registers the new skills. You can run /plugin list to see what is installed and which marketplace it came from.
The third is local plugins. You point the harness at a folder on your machine. This is the one you use for plugins you are still building, or for private team plugins that live in your company's repo.
/plugin install ./packages/my-team-plugin
There is also a /plugin update command for refreshing everything to the latest version, and a /plugin remove for cleaning up. The CLI surface is small and stable.
If you live in a config file instead of a session, plugin entries also go in .claude/settings.json. You can pin specific versions, scope plugins to specific projects, and ship plugin configuration alongside your codebase. For team setups, the file-based approach is the one to standardise on, because it lets new joiners get the same plugin set on day one with a single repo clone.
The Skill Format, Concretely
A skill is a folder with a SKILL.md at the root. The minimum viable skill is twenty lines.
---
name: postgres-migration-reviewer
description: |
Review Postgres migrations for safety before merging. Use when the user
is editing a SQL migration file, asking about migration safety, or asks
to review a database change.
---
When reviewing a Postgres migration:
1. Flag any DROP COLUMN, DROP TABLE, or ALTER COLUMN TYPE as high-risk.
2. Confirm the migration is reversible. If not, the PR description must
explain why.
3. For any NOT NULL added to an existing column, confirm a backfill exists.
4. For any index added on a table over 10M rows, recommend CREATE INDEX
CONCURRENTLY.
Always end with a short verdict: SAFE, RISKY, or UNSAFE, with one line on why.
That is a complete skill. The frontmatter tells Claude when to load it. The body tells Claude what to do once it is loaded. If you save that to ~/.claude/skills/postgres-migration-reviewer/SKILL.md, it is available in your next session.
A more sophisticated skill can include supporting files. A scripts/ folder for shell scripts the skill knows how to run. A references/ folder for reference material the skill quotes. A templates/ folder for boilerplate. The skill body can point to these files with relative paths and Claude will read them on demand. This is how skills stay small in context while still carrying a lot of structured knowledge.
The thing skills are not good at is anything that needs deterministic execution. A skill cannot guarantee that a check ran. A skill cannot block a commit. A skill is a strong suggestion to the model. If you need a hard guarantee, you need a hook. The two compose well: the skill tells the model how to think about the problem, the hook makes sure the resulting action passes a real check.
I have shipped twenty or so skills now. The pattern that consistently produces good ones is to start by writing the skill as a CLAUDE.md snippet in a real project, use it for a week, watch where Claude does the wrong thing, refine the snippet, then promote it to a packaged skill once it stops surprising you. Skills built without that real-use loop are almost always too abstract and the model ignores them in practice.
When To Build A Plugin Instead Of A Skill
The first question I get from teams adopting this stack is "should I build a plugin or just a skill." The answer is almost always "start with a skill" and the reason matters.
A single skill is a five-minute investment. You write the Markdown, you drop it in your skills folder, you use it. If it works, you keep it. If it does not, you delete it. The cost of being wrong is zero.
A plugin is a longer investment. You write a plugin.json, you decide on a directory layout, you add a README, you publish it somewhere, you keep it updated. The cost of being wrong is the time you spent maintaining a packaged thing that nobody used.
The right time to graduate from a skill to a plugin is when one of three things happens.
The first is more than one person needs it. Once your teammate is asking for "that skill you use," the plugin form makes sharing trivial. A plugin in a GitHub repo can be installed by anyone with two commands. A loose SKILL.md in your personal folder is fundamentally yours.
The second is the skill needs supporting infrastructure. If your skill works only when an MCP server is also running, or only when a specific hook is firing, or only when a slash command is registered, you cannot ship the skill alone. The plugin format is the container that bundles all of those pieces together.
The third is the skill has a versioned dependency on something external. If it relies on a specific version of a CLI, a particular SDK shape, or an environment variable being set, the plugin can declare those dependencies and the install process can validate them. The skill cannot.
Outside those three triggers, a skill is the right move. Most of what teams call "we should build a plugin" is actually "we should write three skills and see which one survives."
The Part Nobody Is Talking About: Plugin Provenance
There is a real security story under the marketplace that has barely been discussed, and it is going to matter in the next twelve months.
When you install a plugin, you are installing instructions that the model will follow. A malicious plugin can do things you do not expect. It can include a hook that pipes your file contents to an external server. It can include a skill that tells Claude to commit a backdoor on certain conditions. It can include an MCP server that proxies all your local tool calls through someone else's process. None of this is hypothetical. The capability is there from day one.
The current state of provenance in 2026 is roughly where the npm ecosystem was in 2015. The official Anthropic marketplace is signed and reviewed. Most community marketplaces are unsigned, unaudited, and operated by individuals. A plugin with 50 GitHub stars and a clean README is not the same thing as a plugin you can trust to run on your machine.
The defensive moves are the same ones that mature ecosystems eventually adopt. Pin specific plugin versions in your .claude/settings.json rather than tracking head. Read the plugin.json, the hooks, and the MCP server configs of any plugin before you install it. Treat plugin updates the same way you treat dependency bumps in your codebase, with at least a glance at the diff. If you are working in a regulated environment, run a private marketplace that mirrors only the plugins you have audited.
This is the same defense pattern that applies to AI-generated code security risks. The model and the plugins around it have access to your tools. Trust is not the default. Trust is a thing you earn from sources you have inspected.
I have seen one team get bitten by a plugin that quietly added a hook capturing every prompt and shipping it to an analytics endpoint. The analytics endpoint was the maintainer's own; the intent was telemetry, not malice. The team only found out because their network monitoring caught the outbound traffic. The lesson is not "do not trust plugins." The lesson is "trust plugins the way you trust npm packages, which is carefully."
Building And Shipping Your Own Plugin
Once you have used the marketplace for a few weeks, you will find yourself wanting to ship your own. The flow in 2026 is genuinely friendly.
Start with a folder.
my-plugin/
plugin.json
README.md
skills/
my-skill/
SKILL.md
hooks/
pre-commit.sh
mcp-servers/
my-server.json
commands/
my-command.md
The plugin.json is the manifest. It names the plugin, lists its components, and declares its version. Claude Code uses this to register everything inside the plugin in one go.
Test the plugin locally first.
/plugin install ./my-plugin
Iterate on it the same way you iterate on a CLI tool. Run it, see what breaks, fix the skill or the hook, run again. There is no build step. The plugin is just files. Reload picks up changes in seconds.
When the plugin is ready to share, drop it in a public GitHub repo and write a marketplace.json at the repo root.
{
"name": "my-marketplace",
"plugins": [
{
"name": "my-plugin",
"source": "./my-plugin",
"version": "0.1.0"
}
]
}
That is a working marketplace. Anyone can subscribe with /plugin marketplace add yourgithub/yourrepo and install your plugin by name. You do not need to publish to a central registry. The Git repo is the registry.
For plugins that survive past their first month, version them. Use semver. Keep a CHANGELOG.md. Pin breaking changes to major bumps. The ecosystem is young enough that none of this is enforced, but the maintainers who do it have plugins that get adopted at twice the rate of the ones that do not. The signal that you take maintenance seriously is what tips a team from "I will read the code first" to "I will trust the install."
What I Recommend In May 2026
If you are starting from zero, here is the short stack I would install on a clean machine today.
From the official Anthropic marketplace: the code-reviewer plugin for PR review, the init plugin for new project bootstrapping, the security-review plugin for branch audits.
From the Vercel marketplace, if you ship to Vercel: the Vercel CLI plugin which bundles deployment helpers, AI Gateway routing, Vercel Sandbox tooling, and a handful of MCP servers for project metadata and logs.
From the community marketplaces, three or four skills that match your daily work. For me that is frontend-design, seo-audit, and find-skills (the meta-skill that helps you discover other skills based on what you are working on). For a backend-heavy engineer it might be Postgres helpers, an HTTP debugger, and a Kubernetes context switcher.
From your own repo: a private plugin with your team's CLAUDE.md content broken into skills, plus any hooks that enforce your local conventions. Even a single-skill private plugin pays back the setup cost within a week.
What I would skip on the first install: anything in the "agentic" category that promises to autonomously refactor your codebase or auto-merge PRs. Not because they cannot work. Because the failure mode is hard to recover from when you have not yet built a feel for the surface. Start with skills that suggest. Graduate to hooks that enforce. Reach for autonomous workflows last.
The honest read on the marketplace as a whole is that it is genuinely good, and also genuinely early. The plugins that work are excellent. The ones that do not work waste a session you cannot get back. Read the source before you install. Treat the marketplace like npm circa 2015 and you will be fine.
What This Changes For Developer Tooling
Step back from the implementation details for a second. The marketplace is the first time AI tooling has had a real distribution surface for opinionated workflows. Before this, every team had a CLAUDE.md, a Notion page, a Slack thread of "here is how we use the AI." None of it travelled. None of it got versioned. None of it composed.
The marketplace solves the distribution problem. It does not solve the quality problem, the security problem, or the discovery problem. Those are still open. But distribution is the prerequisite that the rest of the ecosystem can build on. The same way npm being good did not automatically make every npm package good, but did make the package ecosystem possible.
What I expect to happen over the next year. The official marketplace will grow slowly and carefully. The community marketplaces will explode and then consolidate. A handful of curated marketplaces will become the de facto standard. Teams will start running private marketplaces for internal tooling. Plugin signing will arrive. Provenance metadata will get richer. The good plugins will outlast the noise.
If you only do one thing after reading this post, install three plugins this week. One official, one community, one of your own. Run them for a week. See what changed in your workflow. The first marketplace shift will not feel like a productivity revolution. It will feel like the thing you used to type into your system prompt now lives somewhere a teammate can install. Quiet. Composable. The kind of change that compounds.
The dotfiles era of AI tooling is over. The package manager era just started. Worth getting set up early.
Top comments (0)