What is the difference between a Claude Code plugin and a skill?

A skill is one capability: a folder with a SKILL.md holding instructions Claude follows, which you can also invoke by typing its name as a slash command. A plugin is a container that bundles several of those things together and can be distributed and installed: skills, subagents, hooks, MCP server definitions and default settings. So a plugin is not a bigger skill, it is a package that may contain skills. If you wrote one SKILL.md for yourself, you made a skill, not a plugin.

Is a slash command different from a skill in Claude Code?

No, and this is the most common confusion. A skill IS the slash command. A skill at .claude/skills/ship-check/SKILL.md is invoked by typing /ship-check, and the same skill can also be chosen by Claude on its own when its description matches what you are doing. Plugin skills are namespaced, so a skill from a plugin is typed as /plugin-name:skill-name.

When should I use a subagent instead of a skill?

Use a skill when you want Claude to follow a procedure in the conversation you are already having, because a skill's instructions land in the current context. Use a subagent when the work would flood that context or should be answered independently: a subagent runs in its own context window with its own tool access and returns a summary rather than everything it read. A broad search across many files is a subagent. A three-step release checklist is a skill.

Is an MCP server the same thing as a plugin?

No. An MCP server is an external process or endpoint that exposes tools and data over the Model Context Protocol, which is an open standard, so the same server works in other MCP clients. A plugin is a local bundle of Claude Code configuration. A plugin can include an MCP server definition, which is how one install can both add skills and connect a server, but the server itself is a separate thing that runs on its own.

Where do skills, agents and plugins live on disk?

Skills are folders containing SKILL.md, at ~/.claude/skills/ /SKILL.md for every project or .claude/skills/ /SKILL.md for one project. Subagents are single markdown files at ~/.claude/agents/ .md or .claude/agents/ .md. Hooks and permissions live in settings.json at either level. A plugin is a directory with .claude-plugin/plugin.json plus optional skills/, agents/ and hooks/ subdirectories, and it can also carry an MCP server definition.

How do I install a Claude Code plugin?

Add a marketplace, then install from it: /plugin marketplace add followed by /plugin install @ . A marketplace is just a repository with a .claude-plugin/marketplace.json listing its plugins, so there is no single official registry you are limited to. A local directory, a GitHub repo or a Git URL all work.

Do I need a plugin, or is a skill enough?

If it is for you and one repo, a skill is enough and a plugin is overhead. Reach for a plugin when you need to hand the same setup to other people or to several repos, or when the capability is more than instructions: a skill plus the hook that enforces it plus the MCP server it needs. The test is distribution, not complexity.

Plugin, skill, subagent, hook or MCP server — which is which

Five different mechanisms, used as if they were one word. Here is the distinction that actually decides which you want.

Last updated: 2026-09-21 · checked against Claude Code 2.1.278

One sentence each

Five words get used as if they were interchangeable, and they are five different mechanisms. Shortest honest version:

Skill — instructions in a file that Claude follows. Also the slash command.
Subagent — a second Claude with its own context window, for work that would flood yours.
Hook — a script the harness runs on an event, whether or not Claude wants it to.
MCP server — an outside process that hands Claude real tools and data over an open protocol.
Plugin — a package containing any of the above, so somebody else can install it in one line.

The one that catches everyone: a slash command is not a separate thing. A skill at .claude/skills/ship-check/SKILL.md is /ship-check.

The table

	Lives at	Who triggers it	Whose context
Skill	`.claude/skills/<name>/SKILL.md` (or `~/.claude/skills/`)	You type `/name`, or Claude picks it when the description fits	Yours — the instructions land in this conversation
Subagent	`.claude/agents/<name>.md` (or `~/.claude/agents/`)	Claude delegates, or you name one	Its own. You get a summary back, not the transcript
Hook	`settings.json`, under `hooks`	The harness, on an event. Not Claude’s decision	Neither. It is a process with stdin and an exit code
MCP server	`.mcp.json` / `~/.claude.json`, running as its own process or a remote endpoint	Claude calls its tools once connected	Yours, but only the tool results
Plugin	A directory with `.claude-plugin/plugin.json`	Nothing. You enable it; what it contains then behaves as above	n/a

Skill or subagent? The only question that matters

Not “which is more powerful”. Where should the reading pile up?

A skill’s instructions go into the conversation you are already having, so everything it reads stays in front of you and stays in your context. That is exactly what you want for a procedure: a release checklist, a commit convention, the four steps before a deploy.

A subagent gets its own context window and hands back a summary. That is what you want when the honest answer involves reading thirty files and you only need the conclusion. Run it as a skill instead and you will spend your context on file dumps.

Rule of thumb: if you would want to read what it read, make it a skill. If you only want its answer, make it a subagent.

Hook or skill? Also one question

Is it allowed to be skipped?

A skill is something Claude chooses to follow. A hook is something the harness does regardless. “Run the formatter after every edit” written into a skill is a hope; written as a PostToolUse hook it is a fact. This is why “from now on, always…” requests belong in settings.json rather than in a memory file or an instruction.

Hooks are also the part most likely to be quietly broken, because a failing hook says nothing where you can see it — why a configured hook never seems to run.

MCP server or skill?

Does it need to reach something outside your machine? A skill is words. If the capability is “look this up in our database” or “file this ticket”, no amount of instruction gets there; that is a tool, and a tool is an MCP server.

MCP is an open protocol rather than a Claude Code feature, so a server you write works in other MCP clients too. That is the argument for building one instead of a bespoke integration, and the reason a working sample is worth more than a diagram: kit-one-tool-mcp is one tool, a described schema, handled failure paths and 15 tests that run with no API key.

Do you need a plugin?

Probably not yet. A plugin is about distribution, not capability. For yourself, in one repo, a SKILL.md and a hook in settings.json do the whole job and there is nothing to package.

A plugin earns its keep when either of these is true:

Other people need the same setup. Several repos, or teammates who should not each hand-copy four files.
The capability is more than instructions. A skill plus the hook that enforces it plus the MCP server it depends on, installed together or not at all.

Installing one is two lines, and there is no single registry you are confined to — a marketplace is any repo with a .claude-plugin/marketplace.json:

/plugin marketplace add sdvsignal/kit-plugins
/plugin install kit-ship-check@kit-plugins

Four small ones, free and readable, are at github.com/sdvsignal/kit-plugins.

Four things that are commonly said and are wrong

Claim	Actually
“Slash commands and skills are different features”	The same thing. A skill is invoked as `/name`; plugin skills as `/plugin:name`
“A plugin is just a bigger skill”	A plugin is a container. It may hold skills, subagents, hooks and MCP definitions
“A subagent shares the main conversation”	It has its own context window and returns a summary
“MCP servers are a Claude Code thing”	MCP is an open protocol. The same server works in other MCP clients

What does it cost to have someone set this up?

Flat prices, written scope, stop at any rung. No call to book, no retainer.

Rung	What you get	Clock
Free — starter repo	A real setup you copy yourself	now
$29 — Setup Lite	One project: CLAUDE.md, allowlist, one skill, as a pull request you review	24 hours
$99 — Setup Sprint	3–5 skills, hooks, up to 3 MCP servers, plus a runbook	48 hours
$79 — Surface Audit	Already set up and still fighting it: contradictions and an exact fix list	48 hours

Setup Sprint $99 Or start free

Hooks and MCP servers are in Sprint, not Lite — which one you actually need. Clocks run from a complete intake, not from the Stripe receipt.