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

2026-03-03

Claude Code has three different extension mechanisms and the naming is confusing. Here's a clear breakdown of skills, plugins, and subagents — what each one does, when to use it, and how they relate to each other.

Quick comparison

Skills

Skills are reusable prompt templates that encapsulate a workflow. Think of them as slash commands with context.

A skill is a markdown file that tells Claude how to perform a specific task. When you invoke /my-skill, Claude reads the skill file and follows its instructions.

Where they live

• Project skills: .claude/skills/ in your repo
• Installed skills: via claude skills add

Example skill

.claude/skills/review-pr.md:

---
name: review-pr
description: Review the current PR for code quality issues
---

1. Run `git diff main...HEAD` to see all changes
2. For each changed file, check for:
   - Missing error handling
   - Unused imports
   - Type safety issues
   - Missing tests for new functions
3. Summarize findings as a checklist

When to use skills

• Repetitive workflows you do daily (PR review, deploy, test)
• Team-specific processes you want to standardize
• Complex multi-step tasks that benefit from a written recipe

Plugins

Plugins connect Claude Code to external tools via the Model Context Protocol (MCP). When you install a plugin, Claude gains new tools it can call — like querying a Postgres database, searching Jira, or fetching from an API.

How they work

A plugin is an MCP server that exposes tools. Claude sees these tools alongside its built-in ones (Read, Write, Bash, etc.) and can call them when relevant.

Installing plugins

claude plugins add some-mcp-server

Or configure them in .claude/settings.json:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

When to use plugins

• Connecting to external services (databases, APIs, SaaS tools)
• Adding capabilities Claude doesn't have natively
• Giving Claude read/write access to systems outside your filesystem

Subagents

Subagents are Claude instances that Claude spawns to handle subtasks. They're not something you configure — they're a tool Claude uses autonomously to manage complex work.

When Claude encounters a task that would benefit from parallel execution or isolated context, it launches subagents via the Agent tool. Each subagent gets its own context window, does its work, and reports back.

When Claude uses subagents

• Searching a large codebase across many files
• Running multiple independent explorations in parallel
• Isolating noisy work (large test output) from the main context
• Research tasks that require reading lots of documentation

You can influence subagent behavior

While you don't directly control subagents, you can guide Claude:

• "Use subagents to explore this in parallel"
• "Don't use subagents for this, just do it directly"
• Add preferences to your CLAUDE.md

How they work together

These three mechanisms are complementary, not competing:

A skill might use subagents. Your /deploy skill could instruct Claude to use subagents to check multiple environments in parallel before deploying.

A skill might rely on plugins. Your /check-tickets skill could use the Jira plugin to fetch open tickets assigned to you.

Subagents can use plugins. When a subagent is exploring, it has access to the same MCP tools as the parent.

Decision guide

"I want Claude to do X when I tell it to" → Write a skill.

"I want Claude to access system Y" → Install a plugin (MCP server).

"I want Claude to handle complex tasks efficiently" → That's subagents — Claude manages these automatically. Guide with CLAUDE.md if needed.

"I want to enforce a rule Claude can't break" → None of the above. That's a hook. See our hooks guide.