CLAUDE.md vs Skills vs Subagents vs Hooks vs Plugins vs MCP: A Beginner’s Decision Tree
Pick the right Claude Code customization mechanism for your problem in under a minute.
~7 min read

You read three tutorials in one afternoon. The first solved a repeated task with a rule in CLAUDE.md, the second solved something almost identical with a skill, and the third wrote a hook. All three worked. None of them explained why the author picked what they picked, and now you have a pile of mechanisms in your head and no way to choose between them.
That is not a gap in your reading. Claude Code stacks six customization systems that overlap heavily in what they can do while differing completely in when they load and who decides they run. Two more sit alongside them: a memory Claude writes about you without being asked, and the slash-command line you type any of this from. This page is a router. It gives each one a fast, parallel treatment, then hands you a decision tree. It does not teach any of them in depth, because the deep ones have their own guides, linked at the end.
The distinction that clears up most of the confusion
Learn this one split first and half your questions answer themselves. CLAUDE.md and skills are instructions. They go into the model’s context and the model tries to follow them. A hook is code. Claude Code runs it at a fixed point in the session, and the model gets no vote.
Put a line in CLAUDE.md that says "never commit directly to main" and Claude will usually respect it. Usually. It is a strong suggestion sitting in a long conversation, competing with everything else in that conversation for attention. Write a hook that runs right before Claude executes a command, inspects that command, and refuses it, and the commit does not happen, because a shell script decided, not a language model. The official docs put it plainly: memory files are context, not enforced configuration, and blocking an action regardless of what Claude decides is a hook’s job.
So: if something should usually happen, it is an instruction. If something must always happen, it is a hook.
CLAUDE.md: standing facts about this project
CLAUDE.md is a plain markdown file you write, and it loads into context at the start of every session in that project. It is the right home for what is true all the time: the build command, the test command, the conventions a newcomer would otherwise guess wrong. It is a bad home for a ten-step procedure you run twice a month, because you pay for its full length in every session whether that procedure comes up or not.
There is a second memory system beside it. Auto memory is notes Claude writes about you and your corrections, saved per project and loaded automatically, and you never author it by hand. Worth knowing it exists so you are not startled when Claude remembers a correction from last week.
Skills: a known-good procedure, on demand
A skill is a folder with a SKILL.md inside it: a description at the top saying when to use it, and a body underneath saying how. Only the frontmatter sits in context all the time, roughly a hundred tokens of it. The body loads when the skill is actually invoked. That is exactly why a skill is right for the ten-step procedure CLAUDE.md was wrong for. You invoke it by typing its name as a slash command, or Claude matches your request against the description and invokes it for you.
Subagents: a second context window for a side task
A subagent is a separate assistant with its own context window, its own system prompt, and its own tool permissions. You delegate a task to it, it works in isolation, and only its summary comes back. The point is context hygiene: a wide search across a large repo would flood your main conversation, so you send it elsewhere and get back the few lines that mattered. Type /agents to see what is defined. Subagents have their own beginner guide, linked at the end.
Hooks: code that runs whether the model likes it or not
A hook is a shell command Claude Code runs at a fixed lifecycle point: before a tool call (that event is named PreToolUse), after a tool call, when you submit a prompt, when a session starts or ends, and several others. Claude Code fires it. The model cannot decide to skip it, cannot be talked out of it, and cannot forget. That determinism is the whole value and also the whole limit: a hook does exactly what its script does and nothing else. Format on save, block edits to a secrets file, write an audit log. Those are the classic three. A companion guide builds a real working hook and sets it beside a skill line by line, which is the fastest way to feel the difference.
Slash commands, plugins, and MCP servers
A slash command is how you type any of this. Some are built-in utilities with fixed logic (/clear, /compact, /model) and some are just skills invoked by name. That second half surprises people: a file at .claude/commands/deploy.md and a folder at .claude/skills/deploy/SKILL.md both give you /deploy, and they are the same mechanism. Any tutorial presenting custom commands and skills as two separate systems is out of date.
A plugin is a box. One install brings in skills, subagents, hooks, and MCP servers together, from a single source. You decide once, at install time, and everything inside then behaves like the individual mechanism it is. Reach for it when you want somebody’s whole toolkit rather than one file, especially across a team.
An MCP server connects Claude to something outside your filesystem: a database, an issue tracker, a browser, a vendor API. It supplies tools, and Claude calls them the way it calls any other tool. The tell is simple. If you are copying data out of another system and pasting it into chat, connect the system instead.
The decision tree
Read down and stop at the first branch that matches. They are ordered by how often a beginner actually needs them.
- You want Claude to know a fact about this project every time, like the test command or the deploy target or a naming convention: put it in CLAUDE.md.
- You keep re-pasting the same multi-step instructions: make it a skill. This is the most common right answer and the one beginners reach for least.
- It has to happen every time, no exceptions, even when the conversation goes sideways: write a hook. Anything you would phrase as "always" or "never" with real consequences belongs here, not in CLAUDE.md.
- You want to fire something by name, on purpose, rather than let Claude decide: that is a slash command, which in practice means writing a skill and typing its name.
- The task will produce a mountain of output you do not want in your main conversation, like a wide search or a long test run: delegate it to a subagent.
- Claude needs data or actions from a system outside your files: add an MCP server.
- You want several of the above from someone else, in one step: install a plugin.
- You cannot tell which of two it is: pick the instruction, CLAUDE.md or a skill, because it is cheaper to write and cheaper to undo. Escalate to a hook once the instruction has actually failed you.
These are layers more than rivals. A plugin is a container for the rest, so installing one can add several skills, a subagent, a couple of hooks, and an MCP server in a single step. A skill can call an MCP tool partway through its procedure, and a skill can declare hooks that stay active for the rest of the session once the skill is invoked. Once you can name each piece, reading somebody else’s setup gets much easier, because you can see which layer each part is working on.
Get new guides in your inbox
One task, one guide, done fast. Practical Claude Code skills, zero noise.





