Claude Code Skills vs Plugins: What's the Difference and Which Should You Build?
Skills are specialist playbooks you write once. Plugins are bundles of skills others have packaged. Here's when to build your own vs install someone else's.
When “Skills” and “Plugins” Mean Different Things
The terms get used loosely. Someone in a dev forum says “install the GitHub plugin,” someone else says “I wrote a skill for that,” and it’s not always obvious whether they’re describing the same kind of thing.
In the Claude Code ecosystem, they’re not the same. Skills and plugins have distinct shapes, different authoring models, and different jobs. Conflating them leads to building things you didn’t need to build, or reaching for a config file when you should have installed a package.
This article breaks down exactly what each one is, how they differ, and the practical question of whether to build a Claude Code skill yourself or grab a plugin someone else already packaged.
What Claude Code Skills Actually Are
A skill in Claude Code is an authored instruction — something you write that tells Claude how to handle a specific, repeatable task in your specific context.
The most concrete form of a skill is a custom slash command. You create a Markdown file inside .claude/commands/ (or in the global ~/.claude/commands/ directory for cross-project use), and that file becomes a callable command inside your Claude session.
Custom Slash Commands in Practice
Say your team has a standard PR description format. Instead of re-explaining it every session, you write a skill — a .md file describing the structure, the required fields, what to pull from the diff — and save it as write-pr-description.md. Now /write-pr-description is a command you can call anytime.
The file can include:
- Task description and expected output format
- Context it needs (e.g., “read the staged diff and any open tickets”)
- An
$ARGUMENTSplaceholder so you can pass parameters inline - References to specific files or conventions in your codebase
Custom slash commands support project-level and user-level scope. Project-level commands live in the repo and apply to everyone working on that codebase. User-level commands live in your home directory and follow you across projects.
CLAUDE.md as a Skill Layer
Skills also exist at the configuration level through CLAUDE.md files. These are Markdown files that Claude reads at the start of every session — they encode persistent instructions about how to behave in a given codebase.
A well-written CLAUDE.md is essentially a collection of skills baked into ambient context:
- “Always run tests before committing”
- “This codebase uses our internal
@company/utilslibrary for date formatting — don’t use moment.js” - “When writing API endpoints, follow the pattern in
src/api/users.ts”
The key thing about skills is that you write them. They capture your domain knowledge, your team’s conventions, your project’s quirks. They’re not generic — and that’s the point.
The Mental Model for Skills
Skills are playbooks. They encode “here’s how we do X around here.” They’re worth writing when the task is repeatable, specific enough that Claude wouldn’t reliably figure it out from scratch, and unique enough that no one else has packaged it for you.
What Claude Code Plugins Actually Are
A plugin is a packaged capability that someone else has built and made available for installation. Rather than writing instructions, you’re adding a new tool or set of tools to Claude Code’s environment.
The primary plugin mechanism in Claude Code is MCP — the Model Context Protocol. MCP is an open standard that defines how AI systems can connect to external tools, data sources, and APIs. An MCP server exposes capabilities that Claude can call: read a database, search the web, post a Slack message, query an API.
How MCP Servers Work as Plugins
An MCP server runs as a separate process. When you configure it in your Claude Code settings (via .claude/settings.json or ~/.claude/settings.json), Claude Code connects to it and discovers what tools it exposes.
From Claude’s perspective, those tools are just additional functions it can call. From your perspective, you’ve installed a plugin.
Common MCP plugins include:
- GitHub MCP — read PRs, issues, and repos; create branches; comment on reviews
- Filesystem MCP — fine-grained file access with explicit permission scoping
- Postgres MCP — run read-only queries against a Postgres database
- Brave Search MCP — real-time web search capability
- Puppeteer MCP — browser automation and web scraping
Most MCP servers are available via npm or as standalone packages you configure with a single command.
Plugins as Bundles of Capability
A plugin typically bundles multiple related capabilities together. The GitHub MCP server doesn’t just do one thing — it exposes tools for issues, PRs, repos, branches, commits, and more. You get the whole GitHub surface area in one installation.
That’s the value of a plugin: someone else figured out the integration, handles auth, manages rate limiting, and keeps the implementation updated. You install it and use it.
The tradeoff is control. You get what the plugin author built. If you need something the plugin doesn’t expose, you’re either filing a feature request or writing a custom MCP server yourself — which at that point starts looking more like building a skill.
The Core Differences, Side by Side
| Dimension | Skills | Plugins |
|---|---|---|
| What it is | Instructions/commands you write | Packaged tools you install |
| Authoring | You write it | Someone else (or you, to share) |
| Format | Markdown files, CLAUDE.md | MCP servers, npm packages |
| Scope | Task-specific | Capability-broad |
| Specificity | High — designed for your context | Lower — designed for general use |
| Maintenance | You own it | Package author owns it |
| Customization | Fully yours to modify | Limited to what’s exposed |
| Time to set up | Longer (writing takes time) | Faster (install and configure) |
| Best for | Tribal knowledge, project conventions | External APIs, infrastructure, general tools |
The decision isn’t always either/or. A mature Claude Code setup usually has both: project-specific skills for your team’s workflows, plus plugins for external systems like GitHub, a database, or web search.
When to Build a Skill
Build a skill when the task involves knowledge specific to your context — knowledge an off-the-shelf tool can’t have.
Your Team Has a Repeatable Workflow
If your team does the same multi-step task more than twice a week, it’s a skill candidate. Code review checklists, deployment steps, incident write-up templates, database migration patterns — these are things Claude won’t know unless you tell it.
A well-written skill turns that tribal knowledge into a callable command. New engineers benefit immediately; experienced engineers stop repeating themselves.
The Task Requires Project-Specific Context
Some tasks only make sense within your project’s architecture. Writing a new API endpoint “the right way” means following your conventions, not a generic pattern. Writing tests means using your test helpers, your factories, your mock patterns.
CLAUDE.md skills are especially good here. They front-load all the context that would otherwise require a multi-paragraph explanation at the start of every session.
You Need Exact, Predictable Behavior
Plugins give you what they expose. Skills give you exactly what you write. If you need Claude to follow a specific output format, check specific files, or apply specific rules, a skill is more reliable than hoping a plugin behaves the way you want.
Signs You Should Build a Skill
- You find yourself typing the same context block at the start of every session
- A task is well-defined but specific to your domain or codebase
- No existing plugin does exactly what you need
- The task doesn’t require calling external APIs — it’s pure reasoning or code manipulation
When to Install a Plugin
Install a plugin when you need to reach something outside Claude Code’s native capabilities — and someone has already done the integration work.
External APIs and Services
Claude Code can’t talk to GitHub’s API, your database, or Slack without a bridge. MCP plugins are that bridge. If you need Claude to query a Postgres database, read issues from GitHub, or search the web in real time, a plugin is the right answer.
Building this yourself isn’t wrong, but you’d essentially be writing an MCP server from scratch. For well-supported external services, someone almost certainly has already built it.
General-Purpose Capabilities You’ll Reuse Everywhere
Some capabilities are useful across every project: web search, file system access with scoped permissions, browser automation. These don’t need to be customized per project. Install once, configure access, use everywhere.
Time Matters
If you need a capability now and someone has packaged it well, installing a plugin is faster than writing a skill. A well-documented plugin is ready to use in minutes. Skill-writing requires clarity about the task, drafting, iteration, and testing.
Signs You Should Install a Plugin
- You need to call an external API or service
- The capability is general — web search, database queries, file access
- A well-maintained package already exists
- You don’t need to customize how the capability works internally
Using Skills and Plugins Together
The most effective Claude Code setups use both — and they’re designed to complement each other.
A typical pattern:
- Install plugins for infrastructure — GitHub access, database queries, web search. These are the building blocks.
- Write skills for workflows — custom slash commands that combine those capabilities into task-specific sequences. A
/fix-bugskill might search the web for documentation context, query the database schema, and write the fix following your team’s conventions.
Think of plugins as the tools in a toolbox and skills as the instructions for how to use those tools to build something specific to your project.
You can also write skills that explicitly reference plugin-provided capabilities. A CLAUDE.md instruction like “when debugging, use the Postgres MCP tool to check query logs rather than reading log files directly” ties your authored workflow to an installed capability.
Building Your Own Plugin
There’s a third option worth naming: building your own MCP server. This makes sense when:
- You have internal APIs that no public plugin covers
- You want to share a capability set across your whole team or org
- You’re building something general enough to package but specific enough that no public plugin exists
Building an MCP server is more involved than writing a slash command — it requires standing up a separate process. But the Model Context Protocol documentation is well-maintained, and SDKs exist for Node.js, Python, and several other languages.
How MindStudio’s Agent Skills Plugin Fits In
If the skill/plugin framework sounds familiar, it’s because MindStudio uses exactly the same structure — and makes it immediately practical for Claude Code users.
MindStudio’s Agent Skills Plugin is an npm SDK (@mindstudio-ai/agent) that gives Claude Code access to 120+ typed capabilities as direct method calls. Things like:
agent.sendEmail()agent.generateImage()agent.searchGoogle()agent.runWorkflow()
These are plugins in the exact sense described above — pre-built capabilities that handle auth, rate limiting, and retries so you don’t have to. Install the package, call the method.
But where it gets more interesting is that MindStudio workflows are themselves a form of skill. When you build a workflow in MindStudio — say, a multi-step process that pulls data from Airtable, runs it through an AI model, and posts a summary to Slack — you can expose that workflow to Claude Code via agent.runWorkflow(). Your custom workflow becomes a callable capability.
So you’re writing skills (MindStudio workflows) and surfacing them through a plugin (the @mindstudio-ai/agent SDK). The two layers work together exactly as described throughout this article.
For teams building Claude Code agents that need to take real-world actions — send messages, generate content, run business processes — this is a practical way to skip the infrastructure layer and focus on the reasoning. You can try MindStudio free at mindstudio.ai.
Frequently Asked Questions
What is a skill in Claude Code?
A skill is a reusable instruction set you write for Claude Code. The most common form is a custom slash command: a Markdown file in .claude/commands/ that becomes callable as /command-name. CLAUDE.md files also function as skills by encoding persistent context about how Claude should behave in a project. Skills are authored by you and designed for your specific workflows.
What is a plugin in Claude Code?
A plugin in Claude Code is a packaged set of capabilities installed from an external source — most commonly an MCP (Model Context Protocol) server. Plugins let Claude Code connect to external tools, APIs, and services like GitHub, databases, web search, or Slack. You configure them in settings rather than write them from scratch.
Can I use Claude Code skills and plugins at the same time?
Yes — and you should. The best Claude Code setups use plugins for infrastructure (external APIs, databases, web access) and skills for task-specific workflows. Skills can reference plugin tools explicitly, building higher-level workflows on top of installed capabilities.
How do I create a custom skill in Claude Code?
Create a Markdown file in your project’s .claude/commands/ directory (or ~/.claude/commands/ for global use). Name it after the command you want to invoke. Write the task description, expected behavior, and any context Claude needs. Use $ARGUMENTS as a placeholder for parameters. The file becomes a slash command immediately — no restart required.
What MCP plugins are available for Claude Code?
A growing library of MCP servers covers common integrations: GitHub, GitLab, filesystem access, Postgres, SQLite, Brave Search, Puppeteer, Slack, Google Drive, and more. Most are available via npm. Anthropic maintains a directory of official and community MCP servers on GitHub.
Should I build a skill or a plugin for my team’s internal tools?
For internal tools that only your team uses, a skill (CLAUDE.md or custom slash command) is usually the right starting point — faster to write, easier to maintain. If the capability needs to be shared across many agents or projects, or involves complex infrastructure like auth and rate limiting, packaging it as an MCP server is worth the extra work.
Key Takeaways
- Skills are authored instructions — custom slash commands and CLAUDE.md configurations that encode your domain knowledge and team workflows.
- Plugins are installed capabilities — MCP servers that connect Claude Code to external tools, APIs, and services.
- Build a skill when the task is specific to your context, repeatable, and requires knowledge only your team has.
- Install a plugin when you need external API access or a general capability someone has already packaged well.
- Use both together — plugins provide the tools, skills define how to use them for your specific workflows.
- MindStudio’s Agent Skills Plugin shows how the two layers work together: install the plugin to access 120+ capabilities, then expose your custom workflows as callable skills from Claude Code.
Getting this distinction right early pays off. The right layer for the right job keeps your Claude Code setup maintainable as your needs grow. Start exploring what’s possible at MindStudio.