Claude Code Feature
Claude Code Plugins: What They Are and 3 Ready-to-Use Examples
A practical walkthrough of plugins, Claude Code's way of bundling skills, commands, hooks, and MCP servers into one shareable package.
A plugin bundles several Claude Code features together into one thing you install in one step: a skill, a slash command, a hook, an MCP server connection, even a whole subagent, all packaged under one name instead of configured separately in every project. Plugins come from a marketplace, which is just a catalog of where to find them, not a hosted app store. This guide covers what a plugin actually is, how installing one works, and walks through three complete examples: adding a marketplace and installing from it, the smallest manifest a working plugin needs, and a plugin that adds its own slash command. It's aimed at someone who has already used Claude Code for a while and wants to stop re-creating the same setup, the same skill, the same hook, by hand in every new project they start.
A Claude Code plugin is a directory of components, such as a skill, a slash command, a hook, or an MCP server connection, that installs and loads as one named unit instead of being configured piece by piece. Plugins are distributed through a marketplace, a catalog file listing which plugins exist and where to fetch each one, not a hosted store Anthropic runs itself. You add a marketplace once with a slash command or a shell command, then install a specific plugin from it at a scope of your choosing: just for you, for everyone on a project, or only on your own machine.
Published
Free lesson · no account neededMeet ClaudeWhy Claude?6 minStart the free lessonKey Takeaways
- A plugin bundles skills, commands, agents, hooks, and MCP server connections into one named package instead of configuring each one separately per project.
- Plugins come from a marketplace: a catalog file listing available plugins and where to fetch them, which is a different thing from a hosted app store.
- Only a plugin's name is a required field in its manifest; everything else, including every component type it can bundle, is optional.
- Claude Code shows a trust warning before installing any plugin, because a plugin can run real code with your own user permissions, outside Claude's own tool-permission sandbox.
- Auto-update is only on by default for official, Anthropic-maintained marketplaces; community and third-party marketplaces update only when you choose to.
- You can validate a plugin's structure before shipping it with a dedicated command, which catches manifest mistakes before anyone tries to install it.
Copy and Paste
Prompts You Can Use Today
Add a marketplace and install a plugin from it
# Inside a Claude Code session /plugin marketplace add your-org/plugins /plugin install formatter@your-org # This opens a details panel: choose user, project, or local scope to finish # Or from your own shell, with no session running claude plugin marketplace add your-org/plugins claude plugin install formatter@your-org --scope project
your-org/plugins and formatter are placeholders for a real marketplace and plugin name. An official, Anthropic-maintained plugin needs no marketplace-add step first, for example /plugin install commit-commands@claude-plugins-official.
The smallest manifest a working plugin needs
# A minimal plugin needs only a manifest naming it, plus one component.
# Layout:
my-plugin/
.claude-plugin/
plugin.json
skills/
review/
SKILL.md
# .claude-plugin/plugin.json
{
"name": "my-plugin",
"version": "1.0.0",
"description": "Review helpers for this team"
}Name is the only field a manifest actually requires. Everything else in a plugin, including skills, commands, agents, hooks, and MCP servers, lives at the plugin's root rather than inside the .claude-plugin folder. Check the structure with claude plugin validate ./my-plugin before sharing it.
A plugin that adds its own slash command
# skills/review/SKILL.md --- description: Reviews a pull request for style and test coverage. Use when asked to review code. --- Review the changed files. Report style problems first, then missing tests.
This file alone, inside a plugin named my-plugin, becomes the command /my-plugin:review after the plugin loads. Claude can also reach for it automatically whenever the description matches what you've asked for, without you typing the slash command yourself.
The Basics
What a Plugin Actually Bundles
A plugin is a directory of components that Claude Code installs and loads together as one unit. Those components can include a skill, an older-style slash command, a subagent, a hook, a whole hooks module written in JavaScript, and a connection to an MCP server, any mix of them, packaged under one plugin name instead of set up piece by piece in every project that wants them.
Most plugins are found through a marketplace, and it's worth being precise about what that word means here: a marketplace is a catalog file listing which plugins exist and where to fetch each one from, not a hosted storefront that Anthropic runs on your behalf. The official marketplace gets added automatically the first time you start an interactive terminal session, unless an organization's managed policy blocks that; community and any other third-party marketplace are never added for you automatically.
Marketplaces fall into three trust tiers worth knowing before you add one: official marketplaces, which only apply to sources from Anthropic's own GitHub organization; community marketplaces, maintained collectively rather than by Anthropic directly; and everything else, which counts as third-party and deserves the most scrutiny before you add it.
Getting One Installed
How Installing a Plugin Works
The commands are similar whether you're inside a running Claude Code session or working from your own shell.
Add a marketplace
A slash command inside a session, or the equivalent shell command outside one, registers a marketplace by its repository, a pinned version, a local path, or a direct URL to its catalog file.
Install a plugin
Installing by name and marketplace works from either a session or a shell. From inside a session it opens a details panel first so you can pick where it applies, rather than installing immediately.
Pick a scope
User scope applies everywhere on your machine, project scope is meant to be committed and shared with a team, and local scope stays on this one repository and this one machine only.
Browse, manage, and update
A single command opens a discover view for finding new plugins and an installed view for what you already have; separate commands enable, disable, uninstall, or update one plugin or an entire marketplace.
Building One
The Manifest and Standard Layout
A plugin's manifest lives at .claude-plugin/plugin.json inside the plugin, and it's technically optional: the only field that's actually required, if you do include a manifest, is the plugin's name, written in lowercase with hyphens. Everything else sits at the plugin's root rather than inside that .claude-plugin folder: a skills directory with a SKILL.md file per skill, a commands directory for the older slash-command format, an agents directory for subagents, a hooks.json file for bundled hooks, a .mcp.json file for MCP server connections, and a bin directory whose contents get added to your shell's path while the plugin is enabled.
Beyond the required name, a manifest can declare a display name, a version that pins users to exactly that release, a description, author and license information, a homepage link, keywords, and whether the plugin is enabled by default. Any field the manifest schema doesn't recognize gets quietly stripped out with a warning rather than causing a hard failure, which is a forgiving way to handle a manifest written against an older or newer version of the format.
Every component a plugin provides is namespaced under the plugin's own name, which avoids collisions between plugins that happen to use the same short name for something. A skill called "review" inside a plugin called "my-plugin" becomes the command /my-plugin:review, and an MCP server a plugin provides is addressed the same namespaced way when you're writing a permission rule or a hook matcher that needs to reference it specifically.
Before You Trust One
Plugins Run Real Code on Your Machine
It's worth being direct about what installing a plugin actually means: it can run code on your machine with your own user privileges, and components like hooks, MCP servers, and anything in its bin folder run outside the normal permission sandbox that governs Claude's own tool calls. Claude Code shows an explicit trust warning before you install, update, or even just use a plugin for the first time, stating plainly that installing something is not a guarantee it was reviewed or that it won't change later.
The practical habit this suggests is simple: before installing a plugin you don't already trust, open its details and read through what it will actually install, specifically any hooks.json file, any MCP server definitions, and every file in its bin folder, since those are the parts that run outside the sandbox. Auto-update is only turned on by default for official, Anthropic-maintained marketplaces; community and third-party marketplaces update only when you choose to, which gives you a natural checkpoint to review what changed before accepting it.
If you do decide a plugin isn't one you want anymore, uninstalling it removes it from the scope you installed it at, though its cached files can stick around locally for a short period afterward. None of this is meant to suggest plugins are unusually dangerous compared to other software you install; it's the same ordinary caution that applies to installing any third-party code, applied to a system that makes installing that code unusually easy.
Common Patterns
What People Actually Package as a Plugin
A plugin is worth building once you'd otherwise be copying the same setup into more than one project.
A team's shared review skill
A skill that reviews code against a team's own standards, bundled as a plugin so every repository the team touches gets the same review behavior without copying a SKILL.md file around by hand.
A connected tool, pre-wired
An MCP server connection to an internal service or a SaaS product, packaged with the plugin so a new team member gets it working with one install instead of hand-configuring a connection themselves.
A house safety rule
A hook enforcing something an organization always wants, like blocking a specific destructive command pattern, shipped as a plugin so it travels with every project rather than being reconfigured by each contributor.
A packaged workflow
A slash command that kicks off a multi-step routine, like preparing a release or drafting a changelog, bundled with any subagent or hook it depends on so the whole thing installs as one unit.
Packaging Your Own Workflow Is a Transferable Skill
Deciding what belongs in a shared project setup versus a personal one, and reading a new tool's permissions before trusting it, are exactly the habits Nightschool AI's free lesson on setting up a Claude Code project builds from day one.
Frequently Asked Questions
What is a Claude Code plugin?
A directory of components, such as a skill, a slash command, a hook, a subagent, or an MCP server connection, that installs and loads together as one named unit, instead of being set up piece by piece in every project.
What is a plugin marketplace?
A catalog file listing which plugins exist and where to fetch each one, not a hosted app store Anthropic runs on anyone's behalf. The official marketplace is added automatically on first interactive use; a community or third-party marketplace has to be added deliberately, by its repository, a pinned version, a local path, or a direct URL.
What fields does a plugin manifest actually require?
Only the plugin's name, written in lowercase with hyphens. Every other field, including version, description, author, and every component the plugin bundles, is optional.
Where do a plugin's files live relative to the manifest?
At the plugin's root, not inside the .claude-plugin folder. The manifest itself sits in .claude-plugin/plugin.json, but skills, commands, agents, hooks, and MCP server definitions all live alongside it at the top level.
Is it safe to install a plugin from a random third-party marketplace?
Treat it the same as installing any other unreviewed third-party code: a plugin can run with your own user permissions, and parts of it, including hooks, MCP servers, and anything in its bin folder, run outside Claude's permission sandbox entirely. Read what it will install, especially any hooks or MCP server definitions, before trusting it, the same way you'd read through an unfamiliar npm package or browser extension before adding it to something you rely on.
Do plugins update automatically?
Only for official, Anthropic-maintained marketplaces by default. Community and third-party marketplaces update only when you choose to, which gives you a chance to review a change before accepting it.
How do I know what's going to get installed before I install a plugin?
Open its details view inside a session before confirming the install, which shows exactly what it will add. Reading its hooks.json file, any MCP server definitions, and every single file in its bin folder covers the specific parts that run outside the normal permission sandbox entirely.
Can I check a plugin I'm building before sharing it with anyone?
Yes. A dedicated validate command checks a plugin's structure and manifest against the expected format before you ship it, which catches mistakes early rather than after someone else tries to install it. Running the same check in a stricter mode as part of a continuous-integration pipeline is a reasonable habit once more than one person is contributing components to the same plugin.
Build Workflows Worth Sharing
Knowing what to package, what to keep personal, and what to read before you trust it.