Claude Code Plugins vs Skills: What's the Difference?

Welcome, Developer 👋

I’ve been using Claude Code daily for a while now. And one of the things that confused me early on was the difference between plugins and skills. The docs cover both, but they’re on separate pages and it’s easy to come away thinking they’re just two words for the same thing.

They’re not. And once the distinction clicked for me, I started using both a lot more deliberately.

So let me break it down the way I wish someone had explained it to me - what they are, how they differ, and how to install and manage them.

Wait - do you even need Claude Code?

Short answer: no, not for everything.

Skills and plugins work across multiple surfaces. Here’s where you can use them:

Claude Code (terminal CLI) - the focus of this post. Full plugin system, /plugin manager, slash commands. Everything described here applies there.

Claude.ai / Cowork (browser) - you can upload custom skills directly from Customize > Skills in your account settings. No terminal needed. Just zip your skill folder and upload it. This works on Free, Pro, Max, Team, and Enterprise plans, as long as Code execution is enabled in your settings.

npx claude-plugins - a community-maintained CLI that wraps the two-step marketplace-then-install process into one command. Handy if you want to install a plugin without being inside a Claude Code session:

npx claude-plugins install @anthropics/claude-code-plugins/frontend-design

Manual file drop - since skills are just folders with a SKILL.md file, you can also clone a repo or unzip a download straight into ~/.claude/skills/ and Claude Code picks it up. No commands required.

So the terminal /plugin workflow is the most powerful option, but it’s not the only one.

Skills: Instructions You Give Claude

A skill is a Markdown file with instructions that Claude can follow. That’s really it.

You create a SKILL.md file, put it in the right place, and Claude picks it up. After that, Claude either uses the skill automatically when it seems relevant, or you invoke it directly with /skill-name.

The simplest skill looks like this:

---
description: Summarize uncommitted git changes and flag anything risky
---
 
## Current changes
!`git diff HEAD`
 
Summarize these changes in 2-3 bullet points, then list any risks you see.

That ! syntax is the thing that grabbed my attention. It runs the shell command before Claude sees anything, and injects the output directly into the prompt. So Claude gets actual live data from your working tree, not a guess. You can get more sophisticated with it - injecting gh pr diff, env info, test results - and it changes what Claude can do without you having to copy-paste anything manually.

You also control who triggers a skill. Add disable-model-invocation: true to the frontmatter and Claude won’t auto-invoke it - only you can fire it manually. This matters for things like /deploy or /commit. You don’t want Claude deciding to ship because the code looks ready.

Claude Code Already Ships With Skills

This is the thing I didn’t realize for a while: Claude Code has built-in skills out of the box, before you install anything.

These are called bundled skills. Unlike built-in commands (which run fixed logic), bundled skills are prompt-based - they give Claude detailed instructions and let it orchestrate the work using its own tools. You invoke them just like any other skill:

These are worth knowing about before you go hunting for plugins. For a lot of common tasks, something useful is already there.

How to Install a Skill

Skills don’t get “installed” the way plugins do. You just create the file in the right place and Claude picks it up automatically.

There are three scopes depending on who should have access:

Personal - works across all your projects:

mkdir -p ~/.claude/skills/my-skill
# create ~/.claude/skills/my-skill/SKILL.md

Project - this repo only, shared with the team if committed:

mkdir -p .claude/skills/my-skill
# create .claude/skills/my-skill/SKILL.md

Via ZIP upload on claude.ai - zip your skill folder and upload at Customize > Skills. No terminal needed.

Once the file exists, Claude Code hot-reloads it - no restart needed. The only exception is if you created a brand new top-level skills/ directory that didn’t exist when the session started. In that case, restart once.

How to Check Your Installed Skills

Run /skills inside a Claude Code session. This opens a list of every skill Claude has loaded, with their descriptions.

A few things you can do from that list:

• Press t to sort by token count (useful to spot bloated skills eating your context budget)
• Press Space to toggle whether a skill is visible to Claude or shows in the / menu
• Press Enter to save changes

You can also just type / and browse the autocomplete - every skill shows up there. Or ask Claude directly: What skills are available?

If a skill isn’t showing up, the most common causes are: wrong directory, or you added a new skills/ folder mid-session and need to restart.

How to Use a Skill

/my-skill                  # invoke directly
/fix-issue 123             # with arguments

Skills with a good description in their frontmatter will also be invoked automatically by Claude when the context matches. Set disable-model-invocation: true if you only want manual control.

CLAUDE.md vs Skills - a Quick Clarification

If you’ve been using CLAUDE.md for instructions, here’s something worth knowing: the two tools aren’t the same thing, and putting everything in CLAUDE.md is a common mistake.

CLAUDE.md is always in context. Every token in that file costs you on every single turn.

Skills are loaded only when invoked. The content doesn’t enter the context window until someone (you or Claude) actually uses the skill.

The practical rule is: facts, project conventions, and things Claude always needs → CLAUDE.md. Procedures, workflows, and step-by-step instructions → skills. Once a skill gets invoked it stays in context for that session, but before that it costs nothing.

Plugins: Bundles You Can Share

A plugin is a packaged collection of skills, agents, hooks, and MCP servers - bundled together so other people or your team can install the whole thing in one command.

The structure looks like this:

my-plugin/
├── .claude-plugin/
│   └── plugin.json     ← manifest: name, version, description
├── skills/
│   └── code-review/
│       └── SKILL.md
├── agents/
├── hooks/
└── .mcp.json

The key thing about plugins: all commands are namespaced. A skill called code-review inside a plugin named my-tools becomes /my-tools:code-review. That namespacing exists so multiple plugins can define skills with the same name without conflicting.

How to Install a Plugin

The official Anthropic marketplace is already registered when you start Claude Code. To browse it:

/plugin

This opens the plugin manager with four tabs: Discover, Installed, Marketplaces, and Errors. Navigate with Tab / Shift+Tab.

To install from the official marketplace:

/plugin install github@claude-plugins-official

What’s worth installing first

If you’re just getting started, here’s my opinionated short list:

# Code intelligence (pick the ones that match your stack)
/plugin install typescript-lsp@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
 
# Git workflow
/plugin install commit-commands@claude-plugins-official
 
# Source control
/plugin install github@claude-plugins-official

The LSP plugins are particularly worth it. Once active, Claude gets real-time diagnostics after every file edit - it sees your type errors before you do. The LSP plugins require the language server binary to be installed on your system, so if you see Executable not found in $PATH in the Errors tab, that’s why.

Installing from third-party marketplaces

The two-step process: add the marketplace, then install from it.

# Add a marketplace
/plugin marketplace add anthropics/claude-code       # GitHub repo
/plugin marketplace add https://example.com/marketplace.json  # remote URL
/plugin marketplace add ./my-local-marketplace       # local path
 
# Then install
/plugin install commit-commands@anthropics-claude-code

After installing during a live session, run /reload-plugins to activate everything without restarting. You’ll see a summary like:

Reloaded: 3 plugins, 8 skills, 2 agents, 1 hook, 2 MCP servers

Installation scope

When you install via the /plugin UI (press Enter on a plugin in the Discover tab), you pick a scope:

• User - for you across all projects. This is the default.
• Project - stored in .claude/settings.json, shared with the team.
• Local - just for you in this repo, not committed.

Using Plugins in Practice

This is the part that wasn’t obvious to me at first. Some plugins give you slash commands you invoke manually. Others work in the background and give Claude new capabilities it uses automatically. And some MCP-based plugins (like GitHub) work purely through natural language - no slash command needed at all.

Here’s what using the most popular ones actually looks like.

commit-commands

Install it:

/plugin install commit-commands@claude-plugins-official
/reload-plugins

What you get: three commands that automate your entire git flow.

# Stage changes + generate a commit message based on your repo's existing style
/commit-commands:commit
 
# The full one-shot workflow: commit → push to feature branch → open PR with description
/commit-commands:commit-push-pr
 
# Clean up local branches that were deleted from remote
/commit-commands:clean_gone

The commit message generation isn’t generic. It reads your recent commit history and matches your repo’s style. If your team uses conventional commits, it writes conventional commits. If you write sentence-style messages, it does that. And it checks for .env files before staging - it won’t accidentally commit sensitive files.

Requirements: git installed, and gh CLI authenticated for PR creation.

github

Install it:

/plugin install github@claude-plugins-official
/reload-plugins

This one works differently from commit-commands. It’s an MCP plugin - it gives Claude direct access to GitHub’s API. No slash commands to memorize. You just talk to Claude naturally and it handles the GitHub calls.

Create an issue in my-app for the login timeout bug

Show me the open PRs on my project that need review

What GitHub Actions runs failed on main this week?

List all issues assigned to me across my repos

Review the latest PR and summarize the changes

Claude reads repos, creates issues, reviews PRs, checks CI status - all from inside your session without you switching tabs.

typescript-lsp / pyright-lsp

Install:

/plugin install typescript-lsp@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
/reload-plugins

These ones you don’t invoke directly - they work silently in the background. Once installed, Claude gets real-time diagnostics after every file edit. It sees type errors, missing imports, and syntax issues immediately without running a compiler. If it introduces a bug while editing, it catches it in the same turn and fixes it before handing back to you.

You’ll notice the difference in the quality of edits. It stops making changes that break compilation. That’s the whole value.

Requirements: the language server binary must be installed on your system. For TypeScript that’s typescript-language-server, for Python it’s pyright-langserver. If you see Executable not found in $PATH in the /plugin Errors tab after installing, that’s the binary that’s missing.

code-review

Install:

/plugin install code-review@claude-plugins-official
/reload-plugins

Specialized review agents for pull requests with confidence-based filtering - it only surfaces issues it’s confident about, not noise.

# Review the current PR
/code-review:review
 
# With a focus area
/code-review:review focus on security and error handling

context7

Install:

/plugin install context7@claude-plugins-official
/reload-plugins

This one is subtle but genuinely useful. It gives Claude access to live, version-specific documentation pulled directly from source repos. When you’re working with a library and Claude needs to know the current API, it fetches the actual docs instead of relying on training data.

You don’t invoke it manually. It activates automatically when Claude is working with code that uses a supported library. The result: Claude stops hallucinating method signatures that changed two versions ago.

The pattern across all of these: slash-command plugins are for things you want to control (commits, reviews). MCP plugins like GitHub work through natural language. Background plugins like LSP and Context7 just make Claude smarter without you doing anything extra at all.

How to Manage Installed Plugins

Everything lives under /plugin → Installed tab. Filter by name, enable, disable, or remove from there.

Or use commands directly:

# Disable without uninstalling
/plugin disable github@claude-plugins-official
 
# Re-enable
/plugin enable github@claude-plugins-official
 
# Remove completely
/plugin uninstall github@claude-plugins-official
 
# Target a specific scope
claude plugin uninstall github@claude-plugins-official --scope project

If a plugin’s skills aren’t showing up after install, this usually fixes it:

rm -rf ~/.claude/plugins/cache

Restart and reinstall. That’s the fix nine times out of ten.

The Difference That Actually Matters

I want to be honest about something: the “skills are for you, plugins are for sharing” line is an oversimplification.

Skills can be shared too. Commit .claude/skills/ to your repo and every teammate who clones it gets them automatically. No plugin required. Expo does exactly this - they distribute skills to developers building on their platform through project-level skills in the repo, not a plugin.

So the distinction is really about the distribution mechanism, not about who can access them.

The practical rule: if your team already shares the same repo, commit the skills to it. If you need the same thing across multiple unrelated projects, or you want to distribute to developers outside your codebase, that’s when a plugin earns its overhead.

Start with standalone skills when you’re figuring things out. Graduate to a plugin when you need to distribute beyond the repo.

A Quick End-to-End Example

Step 1 - Create a personal skill:

# ~/.claude/skills/pr-review/SKILL.md
---
description: Review pull request for code quality, security, and test coverage
disable-model-invocation: true
---
 
Review the current PR:
1. Check for missing error handling
2. Scan for hardcoded values
3. Verify test coverage on new code
4. Flag any security concerns
 
!`gh pr diff`

Step 2 - Use it:

/pr-review

Step 3 - Your team wants it. Wrap it in a plugin, push to GitHub:

team-tools/
├── .claude-plugin/
│   └── plugin.json
└── skills/
    └── pr-review/
        └── SKILL.md

The plugin.json is the manifest. At minimum it needs a name, description, and version:

{
  "name": "team-tools",
  "description": "Shared PR review and workflow skills",
  "version": "1.0.0",
  "author": {
    "name": "Dan Castro"
  }
}

The name field is important - it becomes the namespace prefix for all your commands. That’s why the skill becomes /team-tools:pr-review and not just /pr-review.

Step 4 - Everyone installs it:

/plugin marketplace add your-org/team-tools
/plugin install pr-review@your-org-team-tools
/reload-plugins

Now everyone has /team-tools:pr-review. One source of truth, versioned in the manifest.

Conclusion

I’ll be honest. I stayed in standalone skills for a long time before I tried building a plugin. The threshold to jump is lower than it looks. If you have a few skills your team keeps asking you to share, that’s the signal to package them up.

Start with skills. Graduate to plugins when you need to.

Stay focused, Developer!