The four mechanisms that extend Claude Code solve genuinely separate problems. A skill teaches Claude how you want something done. A hook guarantees something happens, regardless of what Claude decides. A subagent protects the main conversation's context by delegating focused work to a clean side process. An MCP server gives Claude access to a system it literally cannot reach without it. Pick the wrong one and you either end up with a "rule" the model can quietly ignore, or an MCP dependency bolted on where plain instructions would have done the job.
Choose a Mechanism by the Job
Start with a single diagnostic question: what is actually missing?
If the answer is "Claude doesn't know how I want this done," that's a skill. Commit message format, PR description templates, lint policy, review checklists. All of it is packaged know-how, loaded on demand when it's relevant, and it runs inside your existing session with no external dependency.
If the answer is "something must happen at a fixed point and I can't trust the model to remember," that's a hook. Hooks fire on lifecycle events like PreToolUse or PostToolUse and run outside Claude's context entirely. The model cannot override them. CodingNomads describes this well: hooks run deterministically with zero LLM involvement and zero context cost.
If the answer is "this sub-task would drag 40 file reads into my main thread," that's a subagent. Separate context window, its own token budget, reports back a summary. Quiet and focused.
If the answer is "Claude needs to actually touch a system it cannot reach," that's an MCP server. Database reads, Slack posts, internal APIs, Notion pages. These aren't knowledge problems, they're connectivity problems, and only MCP solves them.
And CLAUDE.md sits above all of them as the always-on layer. Every session reads it automatically. Keep it under 200 lines, per Anthropic's own guidance, otherwise important constraints get buried and ignored.
Instructions, Tool Access, Events and Isolated Context
What each mechanism actually controls:
- Skills: instructions and context, loaded on demand into the current conversation. No external calls. No event trigger. The model decides when a skill is relevant based on the description in its frontmatter.
- MCP servers: tool access. Claude calls MCP tools the same way it calls any tool, but the execution happens in a separate process via JSON-RPC. An MCP server connects Claude to external systems; a skill tells it how to use them well once it's connected.
- Hooks: lifecycle events.
SessionStart,PreToolUse,PostToolUse,PreCompact. They run deterministically. A hook that blocks a destructive command will block it every time, whether Claude thought it was a good idea or not. - Subagents: isolated context. You hand a subagent a brief; it works independently; it returns a result. A test-writing subagent doesn't need to know about your deployment pipeline. A documentation subagent doesn't need your database schema. That separation is the entire point.
Skills and commands are worth a brief note here because they're easy to conflate. Per the official skills documentation, custom commands are folded into skills, not a separate sixth system. They share the same SKILL.md authoring model. More on that in the next section.
Inventive HQ's breakdown puts it plainly: "A skill changes behavior, a subagent protects context, and an MCP server adds capability, and a hook guarantees an action runs deterministically on an event, regardless of what the model decides to do."
Where Slash Commands Fit into Skills
Custom slash commands are not a separate mechanism sitting alongside skills. They're the invocation surface for skills. When you type /deploy or /review, you're triggering a skill by name. That skill carries the instructions, any linked reference files, and the context for how Claude should handle that task.
The authoring task (writing a SKILL.md with good frontmatter descriptions), the command lookup task (deciding which command name to expose), and the mechanism comparison task (choosing between skills and hooks) are three different reader concerns. They happen to share a file format, which is part of why the confusion persists.
If you're deciding whether to use a skill at all, the question is always: is this knowledge I'd otherwise re-type, or is this something that needs to fire on an event regardless of input? The former is a skill, possibly surfaced as a command. The latter is a hook.
For a deeper look at how CLAUDE.md feeds project context into every session, the CLAUDE.md guide for agencies covers the scoping and file structure in detail.
Compose Mechanisms for One Repository Task
Most real-world setups don't pick one mechanism and call it done. They compose two or three. Here's an illustrative scenario showing how that plays out for a PR workflow:
| Task | Mechanism | Reason |
|---|---|---|
| Enforce PR description format | Skill | Packaged know-how; loads when Claude writes a PR |
| Fetch ticket context from Linear | MCP server | External system Claude can't reach natively |
| Scan >20 files for impact analysis | Subagent | Keeps the main thread clean; returns a focused summary |
| Block commits if tests fail | Hook | Deterministic guarantee; can't be argued away by the model |
| Always-on branch naming rule | CLAUDE.md | Never conditional; needed every session |
| Auto-run linter before file write | Hook on PreToolUse | Needs to fire on an event, not on Claude's judgment |
The linter example is worth pausing on. Moeed's breakdown captures it neatly: "The 'run the linter' part is a skill, Claude can do it, you just want consistency. The 'only commit if it passes' part is a hook, that is a guarantee, not a guideline. They compose."
That's the practical mental model. Skills and hooks often work on the same task from different angles.
Common Wrong Choices and How to Correct Them
A few patterns show up repeatedly:
- MCP server for something that was just knowledge. If you find yourself spinning up an MCP server so Claude can "access" your style guide, stop. That's a skill. MCP is for connectivity to live systems, not for loading markdown documentation.
- CLAUDE.md rule that's actually a hook. Putting "never run
rm -rf" in CLAUDE.md is a suggestion the model can technically work around. APreToolUsehook that blocks the Bash tool on that pattern is a hard stop. If a rule needs to be guaranteed, it belongs in a hook, not in context. - Skill for a task that needs its own context budget. If the work involves reading dozens of files, the token bleed into your main session compounds fast. Spawn a subagent. It gets a focused prompt, does the work, and returns a summary. Your main context stays coherent.
- Subagent for something that just needed an instruction. Subagents have overhead. If Claude just needs to know your migration convention, write a skill. Don't spin up an isolated worker for a knowledge problem.
- Overloaded CLAUDE.md. Past 200 lines, Anthropic's own guidance says critical constraints get lost. Move reference content to skills or split into
.claude/rules/files that load conditionally based on path matching.
If you're building a Claude Code workflow from scratch and want a structured starting point, the Claude Code workflow guide walks through how to sequence these layers for a real repository setup.
Follow the Relevant Implementation Guide
Once you've identified the right mechanism, the implementation paths split cleanly. This post is a navigation and comparison layer, not a setup tutorial. Here's where to go next, by mechanism:
- Hooks setup: the Claude Code hooks guide covers lifecycle events, handler types, and how to write shell and HTTP handlers that run deterministically.
- Subagents: the Claude Code subagents guide explains how to brief a subagent, scope its tool permissions, and handle the result in the parent session.
- MCP servers: if you're building or integrating MCP servers for a production stack, the MCP servers production guide covers server types, transport, and reliability patterns.
- Skills: start with the official skills documentation, which covers SKILL.md structure, frontmatter descriptions, and how custom commands map to skill files.
Don't try to read all four at once before you've decided which mechanism applies. That's how you end up three hours deep into hook configuration when you needed a two-line skill.
FAQ
Is CLAUDE.md a mechanism I should include in this decision?
Yes, but it's a different kind of decision. CLAUDE.md isn't selected at task time. It loads every session automatically. The question for CLAUDE.md is: "does Claude need this information every single time, unconditionally?" If yes, put it there. If the instruction only matters for certain tasks, it belongs in a skill with a specific frontmatter description.
Can a skill trigger an MCP server call?
Yes. A skill can instruct Claude to use available MCP tools as part of a workflow. The skill provides the how (what to ask for, in what sequence, with what formatting expectations) and the MCP server provides the access. They're complementary, not competing.
What's the difference between a subagent and an agent team?
A subagent is a worker you dispatch from the main session to handle a focused sub-task. An agent team is a set of peer sessions that can communicate with each other directly, suited to genuinely parallel collaborative work. For most repository tasks, a subagent is the right call. Agent teams make sense when multiple independent workstreams need to coordinate rather than one session delegating downward.
Do hooks have access to Claude's context?
No. That's the point. Hooks run outside Claude's context and the model cannot override them. This makes them the right tool for hard guarantees: security checks, mandatory linting passes, blocked file patterns. The tradeoff is that a hook can't make nuanced decisions based on what Claude understands about the task. It fires on the event and runs its handler.
When does it make sense to use all four mechanisms together?
When you have a workflow with multiple distinct failure modes: a knowledge gap (skill), a connectivity requirement (MCP), a context-bleed risk (subagent), and at least one action that must be guaranteed regardless of model judgment (hook). Most simple tasks need one or two mechanisms. Reaching for all four on every task adds overhead without benefit.
The sharpest distinction in this whole comparison: a skill is a suggestion Claude reads and follows; a hook is a rule the harness enforces whether Claude agrees or not. Get that one wrong and your "safety rule" is just a polite request.