Claude Skills vs Plugins

The key distinction

Skills and plugins are not competing versions of the same feature.

• A skill teaches Claude how to perform a task through instructions and optional supporting files.
• A plugin packages extensions so they can be installed, versioned, and shared through Claude Code or a marketplace.

The practical consequence is that a plugin may contain several skills. It may also contain no skills and instead supply agents, hooks, MCP servers, LSP configuration, or executables.

Comparison table

Question	Claude Skill	Claude Code Plugin
Primary job	Teach a reusable workflow	Package and distribute extensions
Smallest useful form	A folder with SKILL.md	A plugin directory with metadata or supported component structure
Can load automatically?	Yes, when its description matches a task	The plugin loads its components; individual skills or agents then activate according to their rules
Manual invocation	Often available as /skill-name	Plugin skills are commonly namespaced, such as /plugin-name:skill-name
Can contain scripts or references?	Yes	Yes, directly or through contained components
Can contain agents and hooks?	No, not as peer components of a skill	Yes
Can configure MCP servers?	A skill can explain how to use MCP tools	A plugin can ship MCP server configuration
Distribution	Copy/upload the skill or keep it in a skill directory	Install from a plugin marketplace, repository, or local plugin path
Best fit	One focused procedure	A versioned bundle shared across projects or teams

Use a standalone skill when

• You repeatedly paste the same checklist or procedure.
• The workflow belongs to one project or one user.
• The only required extension is task-specific knowledge, references, or scripts.
• You want to iterate quickly before deciding how to distribute it.

In Claude Code, project skills live under .claude/skills/<name>/SKILL.md. User-level skills can be available across projects. This is the simplest path for a deployment checklist, code-review method, house writing style, or file-generation workflow.

Use a plugin when

• Several skills should be installed and versioned together.
• The package also needs agents, hooks, MCP servers, or LSP support.
• Teammates need a repeatable installation and update path.
• The extension should be discoverable through a marketplace.
• Namespacing is useful to prevent commands from colliding with other packages.

Anthropic’s public skills repository demonstrates this relationship: Claude Code first adds the repository as a marketplace, then installs document-skills or example-skills as plugins. Those plugins make the contained skills available.

Claude and Claude Desktop now surface skills, connectors, and plugins in one Customize directory. That shared discovery interface does not erase the technical boundary: an installed plugin can bundle several component types, while a skill remains the task-specific procedure. See the Claude Skills Marketplace guide for current browse and installation paths.

A concrete example

Imagine a team has a release workflow.

A standalone release-check skill might contain the checklist, version rules, and commands Claude should run. That is enough for one repository.

A release plugin could bundle:

• the release-check skill;
• a release-manager agent;
• a hook that blocks publication when tests fail;
• an MCP connection to the issue tracker;
• an executable that generates the changelog.

The skill remains the procedural knowledge. The plugin is the installation and distribution boundary around the full toolset.

Installation and security differences

A focused skill is usually easier to inspect because its main behavior is in SKILL.md and adjacent files. A plugin has a wider potential surface: manifests, agents, hooks, MCP configuration, executables, settings, and other components.

Before installing either one:

1. Verify the source and exact path.
2. Read the instructions and executable files.
3. Inspect hooks and MCP configuration for automatic or external actions.
4. Confirm the license and maintenance state.
5. Test on a low-risk project before enabling it broadly.

Do not infer that a marketplace entry is safe merely because it is easy to install. Distribution convenience and source trust are separate questions.

Common misconceptions

“Plugins connect services; skills only contain prompts”

That is too narrow. MCP provides external connections; a plugin can package MCP configuration. Skills can contain scripts and resources, not just prompt text.

“I must choose either a skill or a plugin”

You often use both. A plugin is a common way to distribute one or more skills.

“Slash commands and skills are separate systems”

In current Claude Code, custom commands have been merged into skills. Legacy command files still work, while the skill directory format adds supporting files and automatic loading.

Decision rule

Start with a standalone skill when you are proving one workflow. Move to a plugin when installation, versioning, namespacing, or multiple extension components become part of the requirement.

For adjacent choices, compare Skills vs MCP, Skills vs Agents, and Skills vs Commands.

For setup rather than architecture, read How to Use Claude Skills or the focused Claude Code Skills guide.

Primary sources

• Claude Code: Create plugins
• Claude Code: Plugins reference
• Claude Code: Extend Claude with skills
• Anthropic skills repository
• Anthropic: Browse skills, connectors, and plugins