Three extension points, one axis: is the new capability knowledge, isolated reasoning, or external access?
Every non-trivial Claude Code project runs into the same question sooner or later: where does this new capability belong? A team's commit message style. A code reviewer for a security-sensitive area. Access to a company's Linear workspace. All three feel like the same problem — ‘make Claude better at this thing’ — but they map to three different extension points with three different lifecycles.
Get the mapping right and each capability sits in exactly one place. Get it wrong and you'll rebuild it as friction surfaces.
What each one actually is
Skill — packaged knowledge or workflow
A Markdown file (plus optional supporting scripts, templates, or references) that Claude reads when it decides the skill is relevant. Skills can be invoked by the model automatically or by the user via /skill-name. They're the right home for anything that boils down to ‘when doing X, here's how we do it here.’
Subagent — isolated reasoning in a fresh context
A separate model invocation with its own system prompt, its own tool list, and its own context window. Nothing from the main conversation leaks in unless you pass it explicitly. Subagents are the right home for anything you want done in a clean context — reviews, deep research, adversarial checks.
MCP server — external access
A process (local or remote) that exposes tools the model can call. MCP servers are the right home for anything Claude needs to reach outside the current filesystem: databases, APIs, browsers, ticket trackers, docs.
The decision tree
Three worked scenarios
Scenario 1 — ‘Review my PRs for security issues in payment code’
The instinct: write a skill called security-review with a checklist. That works for tiny reviews but hits a wall fast — the main conversation's context is full of other work, and Claude has to hold the checklist AND the code AND the reasoning in one head.
The right choice: a subagent. A fresh context gives you a clean review free of distractions, the subagent's tool list can be locked to read-only (Grep, Read, Bash), and its system prompt encodes the checklist as instructions the model doesn't have to hold in working memory. Invoke it after any change to payment code — either explicitly or via a hook.
Scenario 2 — ‘Let Claude post updates to our Linear workspace’
The instinct: write a skill that describes the Linear API and lets Claude use curl. This works, sort of — until authentication rotates, or a new endpoint ships, or you want the model to introspect available issues before writing.
The right choice: an MCP server. Linear's official MCP exposes typed tools (create_issue, list_issues, update_status) with proper auth. The model calls them like any other tool. When Linear ships a new capability, you update the MCP server, not your skill. And rate limits, retries, pagination — the MCP server handles them once instead of in every prompt.
Scenario 3 — ‘Follow our team's commit message convention’
The instinct: write a subagent called commit-writer. This overshoots — spinning up a fresh context for a two-line commit message is expensive and slow, and the main model already knows the diff.
The right choice: a skill. A short Markdown file describing the format (subject line style, footer conventions, breaking-change markers) is exactly the shape of packaged knowledge. Invoke it via /commit or let the model pick it up when it decides to write a commit. No new context, no external calls — just knowledge injected at the right moment.
The comparison table
| SKILL | SUBAGENT | MCP SERVER | |
|---|---|---|---|
| What it packages | Knowledge / workflow | Isolated reasoning | External tool access |
| Where it lives | Markdown file in .claude/skills/ | Markdown file in .claude/agents/ | Separate process; wired via .mcp.json |
| Context | Main conversation | Fresh, isolated | N/A (server, not model) |
| Cost per invocation | Cheap (model reads file) | Expensive (new inference) | Cheap (a tool call) |
| Invocation | Auto or /name | Explicit Task call or agent registry | Model chooses when to call the tool |
| Best for | ‘How we do X here’ | Second opinion, deep review | Databases, APIs, browsers |
| Failure mode | Model may not invoke | Latency, cost, less shared context | Auth, rate limits, availability |
The overlap trap
Two temptations lead to duplicated work.
‘I'll put the knowledge in the subagent's system prompt.’
Now you have two copies of the same knowledge — one in the skill (for the main conversation) and one in the subagent prompt. When you update one, you forget the other. Better: keep knowledge in a skill the subagent's prompt tells it to read.
‘I'll put the API access in the skill.’
Now the skill has hard-coded credentials, endpoints, and error handling — all of which will drift. Better: skill describes when to use the tool, MCP server owns how.
curl template with an auth header, that's an MCP server waiting to be written. If your subagent's system prompt has more than a few paragraphs of ‘how we do X’, that's a skill it should be reading.What about hooks and plugins?
Hooks and plugins are adjacent but different layers. Hooks fire on tool events — they're not model-invocable, so they don't fit the skill/subagent/MCP axis. Plugins are the packaging layer above skills (and subagents, and MCP configs) — a plugin is how you distribute a set of the above, not a fourth option alongside them.
Worked examples
Two real workflows — one from a SaaS engineering team, one from a marketing team — showing how the same three extension points combine into an end-to-end pipeline.
Example 1 — Tier-1 customer support automation (engineering)
A SaaS company gets ~200 support tickets a day. Roughly 60% are ‘how do I…’ questions with answers in the docs. 30% are account-state questions (password reset, subscription status, invoice reprint). 10% need a human. The team wants Claude to take the first pass and only route the hard 10% to a person.
The three-way split falls out naturally:
- MCP owns access — a Zendesk MCP lets Claude read the incoming ticket and update its status; a docs MCP (built on the same knowledge base the humans use) lets Claude search for answers; a Stripe MCP reads account state.
- SKILL owns tone — a
brand-toneskill documents the ‘friendly, precise, never apologetic-without-cause’ voice. Aresponse-templatesskill has the common patterns (‘password reset’, ‘invoice reprint’, ‘cancellation ack’). - SUBAGENT owns escalation reasoning — if the ticket doesn't match any template, spawn an
escalation-summarizersubagent in a fresh context to write a one-paragraph brief for the human, tagged with the customer's plan tier and prior tickets.
The failure this pipeline avoids: putting the tone rules inside the MCP server (so they can't be updated without a server deploy), or putting the Zendesk credentials inside the skill (so every prompt sees the raw API key), or asking the main agent to write escalations in the same context as ‘password reset for John Smith’ (so the escalation summary gets weirdly tainted by earlier tickets).
Example 2 — Content calendar for a marketing team (non-technical)
A marketing team plans a monthly content calendar — blog posts, social posts, newsletter, campaign launches. Currently done in a chaotic mix of Notion, spreadsheets, and Google Docs. They want Claude to help draft the calendar every month, respecting brand voice, past post performance, and the campaign roadmap.
- MCP — a Notion MCP for reading and updating the calendar database; a Google Analytics MCP for pulling last-month's post performance; an HubSpot MCP for campaign schedule.
- SKILL — a
brand-voiceskill (the same one the copywriters use), aneditorial-calendar-formatskill (what fields, what cadence). - SUBAGENT — a
campaign-criticsubagent that reviews the drafted calendar in a fresh context: asks the ‘hostile questions’ the team's editorial lead would ask (‘why this many posts? what if the campaign slips? where's the retention series?’).
Notice the shape: the main agent orchestrates but doesn't own any single capability. Access lives with MCPs. Voice lives with skills. The adversarial ‘yes but’ pass lives with a subagent — a fresh brain, uninfluenced by the drafting context, more willing to poke. Each piece is small enough that a marketing ops person can update it. Nothing is a black box.