As an indie developer moving between several repositories all day, you start to notice that you keep rebuilding the same slash commands and the same MCP setup for each project. For me, the push to take plugins seriously came one morning when I opened a fresh working folder and sighed, "this configuration again." That was the moment I stopped copying snippets around by hand.
A Claude Code plugin bundles extensions — skills, slash commands, MCP servers, and hooks — into a single package you can add or remove with just the /plugin command. Because plugins are distributed through marketplaces, installing one feels like borrowing a setup someone else already polished. The flip side of that convenience is a real trap: it's easy to install something without knowing what's actually inside. So this is both a walkthrough of finding and installing plugins and a note on the check I always run before I press install.
Add a marketplace and browse the shelf
Plugins are distributed in units called marketplaces. Start by adding the official one.
# Run this inside a Claude Code session
/plugin marketplace add anthropics/claude-codePassing a GitHub owner/repo like anthropics/claude-code pulls in the marketplace catalog from that repository. You can also point to a Git URL or to a private repo you host internally.
Once it's added, running /plugin with no arguments opens the browser. It has three tabs, so it's hard to get lost.
- Installed: the plugins you currently have
- Discover: plugins available from your connected marketplaces
- Marketplaces: which marketplaces you're connected to
I'd recommend lingering on the Discover tab at first. Commit helpers, review automation, framework-specific skill sets — just reading the names gives you ideas about which parts of your manual routine you could hand off.
Read the bundle before you install
This is the part I most want to pass along. A plugin isn't just a snippet — it can carry skills, slash commands, MCP servers, and hooks all at once. So what looks like adding a single command can also pull in an MCP server that connects to an external service, or a hook that fires around your file operations.
When I find a promising plugin, I open its repository and look it over with my own eyes before pressing install. Concretely, I read it in this order.
plugin.json(the manifest): which components it declares. If there's anmcpServersentry, that's a sign external connections are involved.- Whether there's a
hooks/directory: hooks fire without you calling them explicitly. I always check which event triggers them and what they run. - Each skill's
SKILL.md: the fastest way to learn what an extension actually does is to read the body, not the summary line.
The official docs also encourage choosing plugins from authors you trust. Even when it looks like adding one command, the surface area of permissions genuinely grows. Making "read it, then install it" a small habit saves you from hunting later for "what was this thing again?"
Installing itself is a single command.
# Specify plugin-name@marketplace-name
/plugin install commit-commands@anthropics-claude-codeSelecting it from the Discover tab in the browser does the same thing.
Choose between User and Project scope
At install time, you pick the scope — how widely the plugin applies. Being deliberate here avoids the later mismatch where "it works in my environment but a teammate doesn't have it."
- User scope installs to
~/.claude/and applies across all your projects. It suits general-purpose tools you use everywhere, like commit-message formatting. - Project scope installs to the working repository's
.claude/and stays limited to that project. Commit the config to the repo, and the whole team shares the same extension.
In my own setup, anything that belongs to my personal habits goes to User, and anything that belongs to a project's conventions goes to Project. Rules like review criteria or quality gates — "in this repo, we do it this way" — go in Project scope and ship with the repository, so a new contributor's environment boots up with the same conventions already in place. This way of thinking is continuous with how you organize your own commands. Reading Claude Code Custom Slash Commands — Build Your Own Commands to Supercharge Team Workflows alongside this makes it easier to judge what to keep at User scope and what to keep at Project scope.
Keep one marketplace of your own
After a while, your interest naturally shifts from "borrowing public plugins" to "bundling and distributing my own setup." A marketplace isn't a special server — it's just a Git repository with a defined structure. Collect the slash commands and skills you kept rebuilding into one repository, make it addable via /plugin marketplace add, and spinning up a new environment becomes remarkably light.
Here too, the more you hand something to others, the more responsibility comes with what permissions it carries. If you include an MCP server, state where it connects; if you add a hook, document its trigger in the README. Becoming the distributor flips the earlier "read it, then install it" into "write it down, then ship it." If you're aiming at unattended execution, the permission-design thinking in Designing Claude Code Skills That Actually Run Unattended — Three Patterns to Avoid Permission-Dialog Stalls carries straight over to plugin distribution.
Start by adding one official marketplace, browse the Discover tab, and open the repository of any plugin that catches your eye. There's plenty of time to press install after you've read what's inside once. Thank you for reading.