Claude Lessons / Guides

Claude Code Skills and Plugins Explained

Claude Lessons team · Updated July 31, 2026

"Skills," "plugins," and "MCP servers" all show up in the same breath when people talk about extending Claude Code, and most explanations blur them together. They're not the same thing, they don't solve the same problem, and using the wrong one for a job is why some setups feel bloated instead of useful. This guide draws the lines clearly, then walks through one real workflow built the right way.

Three different things, one blurry vocabulary

Claude Code has three separate extension mechanisms, and the naming doesn't make the boundaries obvious:

• Skills — instruction files that teach Claude Code how to do one specific task well.
• Plugins — installable bundles that can package skills, slash commands, hooks, and MCP configuration together.
• MCP servers — running connections to external systems (a database, a design tool, an issue tracker) that give Claude Code new things it can look at or act on.

The confusion is fair: a plugin often contains a skill, and a skill can reference an MCP server. They compose. But they answer different questions — a skill answers "how should this be done," a plugin answers "how do I install a whole workflow in one step," and an MCP server answers "what can Claude Code see or touch that it couldn't before." Mixing them up leads people to build a plugin when a five-line skill would do, or to reach for an MCP server when the real problem was just an underspecified prompt.

Skills: a single, focused instruction set

A skill is a markdown file — plus, optionally, supporting templates, scripts, or reference docs — that gives Claude Code detailed instructions for one recognizable task. Unlike a slash command, which you trigger explicitly by typing it, a skill can be picked up automatically when Claude Code judges the current task matches it, based on the skill's description.

Good skill candidates share a pattern:

• You do the task more than once, the same way each time.
• The "right way" to do it has specific rules that are easy to forget or skip under time pressure.
• It's narrow enough to describe precisely — "write a changelog entry in our format," not "write good code."

A skill for writing changelog entries, for example, might specify the exact heading format, which sections are required, how to phrase breaking changes, and where the file lives — details you'd otherwise have to repeat in every prompt, and that Claude Code would otherwise have to guess at.

Plugins: skills, commands, and hooks bundled together

A plugin is a package. Installing one can bring along any combination of: one or more skills, custom slash commands, hooks that run automatically at specific points (see our hooks guide for what those look like), and MCP server configuration — all in a single install step instead of assembling each piece by hand.

The point of a plugin is distribution and consistency, not new capability. Everything a plugin does, you could in principle configure yourself with individual skills, commands, and hooks. What a plugin adds is: one command to install the whole thing, a defined version you can update, and a shape that's easy to share across a team or reuse across your own projects without re-explaining the setup each time.

Where MCP servers fit in

MCP (Model Context Protocol) servers are a different layer entirely. A skill or plugin changes how Claude Code behaves on tasks it can already attempt. An MCP server changes what Claude Code has access to — a running connection to something outside your local files, like a project tracker, a design tool, or a production database. Our MCP guide covers the protocol itself in depth; the short version for this comparison is that a plugin can bundle MCP server configuration as one of its pieces, but MCP servers are useful with or without plugins wrapped around them, and plenty of plugins never touch MCP at all.

Side-by-side comparison

A worked example: one workflow, three ways

Say the recurring task is "open a pull request that follows our team's format." Here's how each layer could handle it:

• Skill only: a skill describing your PR title format, required sections, and linked-issue convention. Claude Code follows it whenever it opens a PR.
• Skill plus slash command: add a /open-pr command that explicitly triggers the same skill on demand, for when you want it invoked deliberately rather than inferred.
• Full plugin: package the skill, the slash command, a hook that runs your linter before the PR opens, and MCP configuration for your issue tracker so the PR auto-links the ticket — all installed together and versioned as one thing your whole team pulls in.

Most teams don't need the full plugin version on day one. Start with the skill, add the command if you find yourself wanting explicit control, and only wrap it into a plugin once it's proven useful enough that you want to hand it to teammates without re-explaining the setup.

Where to find skills and plugins

Community marketplaces and directories list skills and plugins by category — code review, changelog and release workflows, framework-specific helpers, and more. Coverage and quality vary a lot between listings, and the ecosystem moves fast enough that "best of" lists go stale within months. Treat any list, including this guide's advice, as a starting point for search terms rather than a fixed catalog, and check a plugin's own repository for its actual documentation before installing.

Vetting a plugin before you install it

Because plugins can include hooks (which run automatically) and MCP servers (which can hold credentials), treat installing one like adding a new dependency, not like a config tweak:

• Read what it actually does. Open the plugin's source — the skill files, hook scripts, and MCP config — before installing, not after something breaks.
• Check the hooks specifically. A hook that runs on every file edit or every commit has broad reach; know exactly what command it executes.
• Scope it to one project first. Install project-local before granting it access globally across every repo you work in.
• Prefer verifiable sources. An author or marketplace with a track record and visible issue history beats an anonymous one-off repo.

Building your own vs. installing someone else's

Installing a plugin is faster than building one, but it also means trusting someone else's judgment about how a task should be done — and their hooks run with the same permissions yours would. Building your own skill for something specific to your codebase (your PR format, your test conventions, your CLAUDE.md structure — see our beginner's guide for CLAUDE.md basics) is usually a better first move than searching for a plugin that approximates it. Reach for community plugins once you need something genuinely general-purpose, like a well-maintained connector to a common tool, where building your own would just be reinventing infrastructure someone else already got right.

FAQ

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

A skill is a single markdown instruction file (plus optional supporting files) that teaches Claude Code how to do one specific thing, like formatting a changelog or filling out a PR template. A plugin is a packaged bundle that can include multiple skills, slash commands, hooks, and MCP server configuration together, installed as one unit. Think of a skill as one recipe and a plugin as a whole cookbook plus the kitchen tools it needs.

Do I need MCP servers to use skills and plugins?

No. Skills and plugins work with whatever Claude Code can already do — read files, run commands, edit code. MCP servers are a separate extension mechanism that connects Claude Code to external systems like a database, a design tool, or an issue tracker. A plugin can include MCP server configuration, but plenty of useful skills and plugins never touch MCP at all.

Are Claude Code skills the same as slash commands?

They overlap but aren't identical. A slash command is a short, explicitly invoked instruction you trigger by typing /something. A skill is typically more detailed and can be invoked automatically when Claude Code judges it relevant to the task, without you typing a command at all. Plugins commonly package both: a slash command as the trigger and a skill as the detailed instructions behind it.

Is it safe to install community Claude Code plugins?

Treat a plugin like any other code you'd pull into your machine: read what it actually does before installing, especially any hooks (which run automatically) or MCP servers (which get credentials). Prefer plugins from marketplaces or authors you can verify, check for recent activity and issues, and start with plugins scoped to a single project rather than granting broad, always-on access globally.

Should a beginner start with skills or plugins?

Start with neither, and start with a well-scoped CLAUDE.md and clear prompts first — that's most of the value. Once you notice yourself repeating the same detailed instructions across sessions, turn that into a skill. Reach for plugins later, once you want an entire workflow (skill plus command plus maybe an MCP connector) shared across a team or reused across projects.