Skills vs Subagents vs Hooks vs MCP: The Claude Code Decision Guide (2026)

If you have used Claude Code for more than a week, you have probably hit this wall: you want to extend it, you open the docs, and you find four different mechanisms that all sound like "add capability to Claude" - Skills, Subagents, Hooks, and the Model Context Protocol (MCP). They overlap just enough to be confusing, and nobody tells you which one to reach for. I have built and shipped all four in real projects, so this is the decision guide I wish existed. If you are brand new, start with what Claude Code is first, then come back.

Skills vs Subagents vs Hooks vs MCP at a glance

Here is the decision table. Each of these four primitives lives in your .claude directory (or settings.json), and each one answers a different extensibility question. Skim the columns that matter to you: what it adds, what triggers it, whether it gets its own context window, whether it is deterministic, and where you configure it.

The single sharpest distinction in this table: only Hooks are deterministic, and only Subagents get their own context window. Hold onto those two facts and half the confusion disappears.

What is a Skill in Claude Code?

A Skill is a folder with a SKILL.md file that holds instructions, checklists, or domain knowledge Claude loads only when it is relevant. The mechanism is called progressive disclosure: Claude reads a short description of each skill at startup, but it does not pull the full body into context until it decides the skill applies to the task at hand. That means a skill costs almost nothing in tokens until it actually fires. Skills can be auto-invoked by the model or triggered by hand with /skill-name.

.claude/skills/
└── pr-review/
 └── SKILL.md # instructions Claude loads when reviewing a PR

Information-gain correction for 2026: custom slash commands are now merged into skills. An old .claude/commands/deploy.md is functionally the same idea as .claude/skills/deploy/SKILL.md - a lot of older blog posts still treat "commands" as a separate fifth primitive, but the official Claude Code docs (verified 08/2026) fold them into skills. So there are four primitives to reason about, not five.

Reach for a Skill when you want to standardize knowledge or a repeatable procedure - a coding convention, a review checklist, a house style for commit messages. For a full walkthrough, see Claude Code skills explained in depth. The honest limitation: a skill is instructions, not code and not a tool. It cannot reach outside Claude Code on its own - that is what MCP is for.

What is a Subagent?

A Subagent is a specialized assistant with its own context window, its own system prompt, its own tool allow-list, and its own permissions. When Claude hits a task that matches a subagent's description, it delegates: the subagent works independently in its isolated window and returns only a summary to the main conversation. Because it is isolated, the noisy intermediate work - logs, file dumps, dead ends - never pollutes your main context. Subagents can also run on cheaper models (for example Haiku) to keep delegated work affordable.

.claude/agents/
└── code-reviewer.md # name, description, tools, model, system prompt

The best cue for a subagent: a side task would otherwise flood your main context. Deep research across dozens of files, a long log analysis, a self-contained refactor - anything where you only care about the conclusion, not the mess. Learn to chain several of them in a real AI dev workflow with AgentKit.

The honest anti-pattern: over-using subagents burns tokens. Every delegation spins up a fresh context and re-establishes state, so wrapping a two-line task in a subagent is pure overhead. Use them when isolation pays for itself.

What is a Hook?

A Hook is a deterministic shell command that fires on a lifecycle event, configured in settings.json. Unlike the other three primitives, a hook is code, not a prompt - it runs regardless of what the model decides. Common events include PreToolUse (before Claude runs a tool), PostToolUse (after), and Stop (when a turn ends). That makes hooks the right tool for guardrails: auto-format and lint on every edit, block a risky command, scan for secrets before a commit, or fire a desktop notification when a long task finishes.

// settings.json
{
 "hooks": {
 "PostToolUse": [
 { "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": "npm run format" }] }
 ]
 }
}

The key contrast with everything else on this page: a hook does not ask the model's permission. If the event matches, it runs - every single time. That determinism is exactly why you use it for things that must never be skipped. See the deep dive on Claude Code fundamentals if lifecycle events are new to you. The honest anti-pattern: hooks that block too aggressively will fight you on legitimate work, so keep your matchers tight.

What is MCP (Model Context Protocol)?

MCP (the Model Context Protocol) is an open standard that connects Claude Code to external tools and data sources through MCP servers. A server exposes a set of tools - read a GitHub PR, query a Postgres database, drive a browser, hit an internal API - and Claude calls those tools the same way it calls its built-in ones. MCP is what standardizes tool integration so you are not writing a bespoke bridge for every service. Servers are declared in .mcp.json.

// .mcp.json
{
 "mcpServers": {
 "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] }
 }
}

The best cue for MCP: you need Claude to reach a system it does not control - your database, your issue tracker, a live API. If you find yourself copy-pasting data into the chat so Claude can act on it, that job belongs to an MCP server. The honest anti-pattern: reaching for MCP when a plain Skill would do. If you only need Claude to know a convention, that is a skill; MCP is for when it needs to do something in an external system.

The real differences (side-by-side breakdown)

Definitions are easy; the confusion lives in the overlaps. Here is the breakdown on the axes that actually separate the four.

Skill vs MCP is the most common mix-up. A skill adds instructions - it changes what Claude knows and how it behaves. MCP adds capability - it lets Claude touch a system it otherwise cannot. "Follow our PR checklist" is a skill; "read the actual PR from GitHub" is MCP. They frequently work together.

Skill vs Subagent is the second trap. Both feel like "give Claude a specialty," but a skill is in-context knowledge the main model applies itself, while a subagent is an out-of-context worker that goes off and does the job in isolation. If you want the main thread to behave a certain way, use a skill. If you want to offload a task so it does not clutter your window, use a subagent.

Config-location cheat sheet in one place: skills live in .claude/skills/, subagents in .claude/agents/, hooks in settings.json, and MCP servers in .mcp.json. Four primitives, four homes.

When should you use which? (decision by goal)

Skip the theory - start from what you are trying to do. Here are real one-liners mapped to the right primitive:

• I want to standardize a repeatable procedure (review checklist, commit style) → Skill
• I want to keep a research- or log-heavy task out of my main context → Subagent
• I want to force formatting, tests, or secret-scanning every single time → Hook
• I want Claude to query my database, open a PR, or hit an API → MCP
• I want a house convention Claude always follows → Skill
• I want a big refactor done without watching the intermediate noise → Subagent
• I want to block a dangerous command before it runs → Hook

Notice the pattern: knowledge and behavior lean toward Skills, isolation leans toward Subagents, non-negotiable enforcement is always Hooks, and anything that crosses your app's boundary is MCP.

Can you use all four together? (yes - and you should)

These primitives compose; they do not compete. A mature Claude Code setup uses all four at once, each doing the one thing it is best at. Here is a concrete end-to-end example of a code-review flow:

1. A Skill defines your review procedure - what to check, in what order, and your team's standards.
2. Claude delegates the actual review to a Subagent, so the file-by-file analysis runs in its own context and only the verdict comes back.
3. That subagent uses a GitHub MCP server to read the real pull request - diffs, comments, CI status.
4. A Hook blocks the commit deterministically if the tests fail, no matter what the model concluded.

That is the whole point: one skill, one subagent, one MCP server, and one hook, each covering a gap the others cannot. Assembling all of this by hand is real work - you are authoring skill files, writing subagent prompts, wiring MCP servers, and testing hooks. If you would rather not build every piece from scratch, curated kits ship these primitives pre-made; AgentKit for Claude Code (20% off via link) is the one I point people to. More on that next.

Skip the setup - get all four pre-built with AgentKit

Quick disambiguation, because the name collides: this is AgentKit for Claude Code at agentkit.best (CLI ak) - not OpenAI's AgentKit (Agent Builder / ChatKit). Different product entirely.

Read my full, honest take in the AgentKit review before you decide, or weigh it against other options in AgentKit vs the alternatives.

FAQ

Skill vs subagent - which for a repeatable task?

Use a Skill. A repeatable procedure (a review checklist, a commit-message style) is knowledge the main model applies in-context. Only reach for a subagent when that task is heavy enough that you want it isolated in its own context window so it does not clutter your main conversation.

Is MCP a replacement for skills?

No. They solve different problems. A Skill adds instructions and knowledge; MCP adds the ability to reach external tools and data like a database or GitHub. If Claude only needs to know something, use a skill. If it needs to do something in an outside system, use MCP. They often work together.

Are hooks AI or just scripts?

Just scripts. A hook is a deterministic shell command that fires on a lifecycle event such as PreToolUse or Stop. It runs regardless of the model's judgment, which is exactly why it is the right choice for guardrails like auto-formatting, test enforcement, or secret scanning.

Do subagents cost more tokens?

They can. Each subagent spins up its own context and re-establishes state, so trivial tasks wrapped in a subagent are pure overhead. The upside is that keeping heavy work out of your main context can save tokens overall. You can also run subagents on cheaper models to control cost.

Did slash commands become skills?

Yes. As of 2026, custom slash commands are merged into skills - an old .claude/commands/x.md is the same concept as a SKILL.md. Treat commands as a way to invoke a skill by name, not as a separate fifth primitive.

Do I need all four?

Not to start. Most people begin with one or two and add the rest as needs appear. A complete setup does use all four, though, and if you want them ready-made, a curated kit like AgentKit ships skills, subagents, and MCP integrations pre-built so you only wire the hooks yourself.

Conclusion + next steps

The rule of thumb is worth memorizing: add knowledge → Skill; add a tool or data source → MCP; isolate heavy work → Subagent; enforce something deterministically → Hook. Remember the two anchors - only Hooks are deterministic, only Subagents get their own context window - and you will pick the right primitive every time. From here, go deeper on Claude Code skills, or if you would rather start from a pre-built foundation, grab the kit (20% off via link) and read the honest AgentKit review first.