CLAUDE.md vs Skills vs Subagents vs Hooks: Claude Code's Extension Map

Claude Code works fine straight out of the install, but the moment you want to hand off repeated work, you start reaching for extension points like CLAUDE.md, skills, subagents, hooks, and plugins. The names sound alike, but each one replaces something different.

There's a point where the tool names inside Claude Code get confusing before "Claude Code" itself does. Skills, subagents, hooks, and plugins in particular all sound like "does something automatically for you," and nobody tells you upfront which one you actually need, or when. If you've already opened a terminal, installed Claude Code, asked your first question, and connected an MCP server, this confusion is exactly what shows up next. Google autocomplete confirms it: type "claude code subagents" and "vs skills" is one of the first things suggested. You're not the only one stuck on this.

Sort the five apart once, and after that the label alone tells you where to go. Skills, subagents, and hooks are all core Claude Code features, so specifics can shift release to release. If you're reading this well after August 2026, cross-check with the official docs.

Extend

"Extend" is the umbrella term for the five ways you add to Claude Code's default behavior. CLAUDE.md is context that's always on, every session. Skills are knowledge and procedures you load on demand. Subagents are isolated execution slots. Hooks are scripts that fire at a set moment with no human involved. Plugins are the unit that bundles all of the above for distribution.

The five extension devices, compared

The official Claude Code docs, in "Extend Claude Code," lay these five out in a single comparison table. Here it is again, reordered to match this track.

Let's unpack that plugins row, over on the right. A plugin isn't really a fifth thing standing next to the other four; it's closer to packaging. The official docs describe a plugin as bundling skills, hooks, subagents, and MCP servers into a single installable unit. That's why its "what it replaces" cell reads differently from the other four's. The other four replace something you'd build yourself; a plugin replaces the act of installing something someone else already built.

If "when you reach for it" still feels vague, the official docs give sharper signals to watch for. Claude getting the same convention or command wrong twice is the cue for CLAUDE.md. Pasting the same instruction into the chat box a third time is the cue for a skill. Side work filling the conversation with search results and logs you'll never look at again is the cue for a subagent. None of these five need to be in place before the corresponding signal actually shows up. The official docs are explicit that you don't have to configure everything from day one.

The learning order tracks the cost order

There's one rule behind this order. Installing something is cheaper than writing a file. Writing a file is cheaper than working out a procedure and turning it into a skill. That's cheaper than splitting work off to a subagent. And the most expensive of all is automation that runs with nobody watching. Climb from the bottom rung to the top and the amount you have to judge and manage yourself keeps going up.

Even so, this track's actual lesson order doesn't map onto that cost order exactly. On the ladder, installing a plugin should sit below CLAUDE.md, earlier, in lesson terms, but this track puts CLAUDE.md at lesson 2 and pushes plugins to lesson 3. That's not about cost; it's about ingredients. Every lesson that follows, skills, subagents, automation, reuses the rules you write into CLAUDE.md. What you need to prep before you learn the next thing outweighs pure cost, in this case.

Take a look inside the .claude directory

All five extensions exist as files or folders. Seeing where, once, makes every lesson after this one go faster. Claude Code checks two spots: the .claude/ folder inside whatever project you're working in, and ~/.claude/ in your home folder. Per the official docs on "Understanding the .claude directory," a project's .claude/ folder holds settings.json (permissions and hook config), settings.local.json (settings local to just your machine), and folders like skills/, agents/, rules/, commands/. Hooks don't get their own folder; they live as a hooks entry inside settings.json. The home ~/.claude/ adds your personal CLAUDE.md and the projects/ folder where automatic memory accumulates.

I didn't run this check myself until much later. The first time I opened .claude/, there was already something inside it, and I figured it was just managed automatically. I kept building things project by project without ever looking inside. Then one day I found that a folder I'd been working out of for a while was completely empty, and a skill I thought I'd already set up hadn't actually saved right. I'd been assuming everything was fine just because it usually was. That's when it hit me that I needed to learn the folder structure first, and the two commands above are the check I wish I'd run back then.

Why MCP isn't on this list: it points the other way

MCP shows up next to these five constantly, but it's not part of this lesson. The official docs list it in the same table when they cover extensions, but what it actually does is different. CLAUDE.md, skills, subagents, hooks, and plugins are all about what Claude Code decides to do on its own. MCP points the other way: it's the channel that connects Claude Code to an outside service, a database or Slack. You've already covered this twice earlier in this journey. Track 2 (Connect) explained the shared standard itself, and Track 3 (the CLI track) had you make an actual connection with claude mcp add. Covering it again here would be redundant, so this track skips MCP.