Over the first five chapters you have installed Claude Code, given it instructions, worked your way out of the places it gets stuck, and designed its permissions. This chapter is about reshaping the tool itself. Learning the names of the extensions will not get you anywhere. What helps is a lookup table: "which one solves the thing that is bothering me right now".

A map for choosing — four questions decide it

There are six extensions, but only four things to think about. Is asking enough / does it have to fire every time / do you want it in a separate context / do you need to reach outside—ask yourself those in that order and the answer usually comes out unique.

Q1
Is asking enough?

If the occasional miss is not fatal, words will do. → CLAUDE.md (the standing premises) / Skills (steps for one particular job)

Q2
Does it have to fire every time?

If a single miss is a problem, stop it mechanically. → hooks. They run without the model deciding anything.

Q3
Do you want it in a separate context?

If you do not want a flood of output burying the main thread, run it outside and take back only the conclusion. → subagents

Q4
Do you need to reach outside?

When you need information the AI has no way of knowing (the current values in a database, what is in your issue tracker). → MCP

The fifth question is "are you handing this to other people?"—if you are, plugins. The easy ones to confuse are Q1 and Q2: CLAUDE.md, Skills, and hooks. They all look alike, but they differ in when they get read and who executes them.

CLAUDE.md — memory that persists, until it gets too long

CLAUDE.md, placed at the root of a project, is a file that gets read automatically at the start of every session (~/.claude/CLAUDE.md if you want it across all projects). Because it is a file, it is immune to the "the early part gets forgotten when things run long" problem from Chapter 1. It is where the things you explain every single time belong.

"It says it read the file and then ignores it" is not laziness but a structural problem, and it has three causes.

  • The middle sinks—instructions in the middle of a long document are the easiest to miss, and the longer you make it, the more the rules in the middle effectively cease to exist
  • Compaction summarizes it away—once compaction runs, fine-grained operating rules get flattened. That is why violations pile up later in a session
  • The most recent instruction wins—"just commit it" walks straight past a verification procedure that was read hundreds of turns ago

The fix is to cut. As a rule of thumb, what reliably works is somewhere up to 100 to 150 lines. Past that, keep only the rules you cannot break at the top and move the detail into separate files (duplication drifts, so keep one canonical copy). Mark only the undroppable ones "CRITICAL", and write them so someone outside can judge compliance—"three lines or fewer", not "write it carefully".

"I have read it" is not evidence. The only thing to judge on is how it behaves afterwards. A rule that keeps getting ignored no matter how you rewrite it is not a writing problem—it is a job for the next section.

hooks — not a request, a certainty

"Do not rewrite .env"—put that in CLAUDE.md and it will be honored nine times out of ten. If the one time in ten does not hurt you, prose is enough. If it does, use hooks—that is the fork.

hooks are shell commands that run automatically at fixed points. What runs them is not the model but Claude Code itself, the harness, so they fire without waiting on any judgment call. The full picture is covered in What Are Claude Code Hooks? Events, Config, and Use. There are nine standard trigger points.

SessionStart on start or resume UserPromptSubmit right after you submit [can block] PreToolUse just before a tool = gatekeeper [can block] PostToolUse after a tool succeeds = formatting [can block] Notification waiting for input or approval Stop end of a response [can block] SubagentStop subagent finished [can block] SessionEnd session ends PreCompact before compaction [can block]

"Can block" means you can stop the action at that point. Turn dangerous commands away at PreToolUse, format automatically at PostToolUse—those two are the usual way in. The configuration goes under the "hooks" key in settings.json, and where you put the file decides the scope (~/.claude/ = you, .claude/ = shared, settings.local.json = you alone).

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "..." } ] } ] } }

The shape is event name → an array of matcher plus command. matcher is the target tool name (|-separated, as in "Edit|Write"; omit it to match everything). A hook takes JSON on standard input and answers with an exit code—0 for success, 2 to block (standard error is handed to Claude). The target file path is in that input JSON too, so you can write "stop if the path is this one".

Hooks can tighten restrictions, never loosen them. Returning an allow only skips the prompt; deny rules always win. A PreToolUse deny still applies in the mode that skips every approval, so it works as a floor under whatever you loosened in Chapter 5.

The price, up front. Hooks run arbitrary shell commands automatically, with your privileges. The official documentation states it plainly: the responsibility is entirely yours. Configure only what you trust, and validate the input. The configuration is fixed when the session starts, so when you have fixed it and nothing changes, open a new session.

subagents — hand work off in a separate context

The full output of a test run, a huge log—when bulk text you were only ever going to skim piles up, the premises that actually matter get pushed out. subagents run that work in a separate context and hand back only a summary of the conclusion. Each has its own context window, system prompt, and tool permissions, and none of them sees your conversation history, so the debris of an investigation never comes back to the main thread.

  • Worth splitting off—broad investigation / checks that produce a lot of output / self-contained tasks where only the conclusion matters
  • Not worth splitting off—sequential work / frequent back-and-forth / parallel work touching the same file / fixes that take one or two steps

It is a built-in feature, so it works with no configuration. To add your own definition, put it in .claude/agents/<name>.md (~/.claude/agents/ for all projects) with name / description / tools / model in the YAML front matter. Manage them with /agents, call one with @agent-<name>. Start with the built-in exploration, planning, and general-purpose ones.

description is the key to getting called. The main agent reads it to decide whether to delegate, so a vague one never gets called at all. Be specific about what it does and when to use it—the same trap is waiting in Skills.

Agent Teams, easily confused with this, is a mechanism where several independent sessions coordinate through a shared task list. It is an experimental opt-in, off by default (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Separate instances are running, so it burns a lot of tokens, and it cannot be nested. The difference is compared in Claude Code Subagents vs Agent Teams: Which to Use. When in doubt, a single session or subagents.

Skills — turning procedures into assets

For the "always do it this way" kind of routine, what Skills do better is that they are opened only when needed. Physically it is a folder built around a SKILL.md. Put name and description at the top, the procedure in Markdown below that, and bundle reference/ or scripts/ alongside it. Drop it in .claude/skills/ (per project) or ~/.claude/skills/ (everywhere) and it is picked up.

The heart of it is progressive disclosure. All that gets read at the start of a session is each skill's short description; the body and its materials load only once a request matches. That is why you can install dozens of them and barely fill your everyday context—the decisive difference from CLAUDE.md, which is always there in full. The flip side: if nothing matches, it never opens at all. With a vague description, the procedure you wrote may as well not exist. How to write one is covered in What Are Claude Skills (Agent Skills)? A Beginner's Guide.

In one line. CLAUDE.md = premises that are always read, Skills = procedures Claude decides to open, hooks = processing that always runs.

MCP — reaching out to systems outside

The three so far were extensions that change how it works. MCP (Model Context Protocol) alone widens what it can touch—a standard for reaching things the AI structurally has no way of knowing, like the current values in a database or a ticket in an issue tracker. There are two connection shapes, and they get stuck in different places.

  • Local (stdio)—the server starts as a subprocess on your own machine. What gets stuck is the startup itself (paths, environment variables, command resolution)
  • Remote (HTTP)—you connect to a server in the cloud by URL. What gets stuck is almost always authentication, meaning a 401 or a 403 is coming back

So do not lump "it will not connect" into one thing; start by checking the status with /mcp. failed means local startup, needs authentication means remote auth, pending approval means it is waiting on you—the status decides the move. The fixes are collected in Claude Code MCP Connection Error: Causes and Fixes.

A few traps of its own. The shared config .mcp.json goes at the repository root (not under .claude/, and not inside settings.json), and API keys go in the per-server env. On Windows npx is really a batch file, so passing it through cmd as /c npx ... makes it work.

Every server you connect consumes context. The tool definitions alone pile up and squeeze the window. Disabling the servers you are not using is the safe habit.

plugins — bundling a set and handing it out

Once skills, subagent definitions, hooks, and MCP config start scattering, plugins are the way to bundle them into something you can hand out. The directory rules are the easy part to get wrong. The manifest is .claude-plugin/plugin.json, and .claude-plugin/ holds nothing else. skills/, agents/, hooks/hooks.json, and .mcp.json go at the root.

/plugin marketplace add owner/repo ← register a catalog /plugin install name@marketplace ← install individual ones from it /plugin list ← check what is installed

Installation takes two steps. Register the catalog, then install plugins from it one by one—adding the catalog on its own installs nothing. The scopes are user (all projects) / project (everyone working on it) / local (you alone) / managed (distributed by an administrator, not editable), and project is the one for keeping a team in sync. Building your own is covered in Claude Code Plugins and Marketplace: Use, Build, Publish.

A plugin can run arbitrary code with your privileges—the official documentation says so outright. Anthropic does not vet third-party plugins or the MCP servers bundled with them. Install only what comes from a publisher you trust. The permission design from Chapter 5 comes back here as code someone else wrote.

What to add first — a word about order

Six of them, laid out—but you do not need all of them. Adding things before you have a problem only buys you configuration complexity. Start from the symptom.

  • Explaining the same thing every time → CLAUDE.md. Skills instead, if it is only for one particular job
  • Written down but ignored → cut it back first. Move only what causes real damage to hooks
  • The context fills up fast → push heavy investigation into subagents / disable MCP servers you do not need
  • The AI cannot reach the information → MCP. Connect one at a time, and move on only after you have seen it work
  • You want to hand the same setup around → plugins. Bundle only what already works for you
  • Nothing is bothering you → add nothing. That is the best state to be in

That last line is not a joke. Every extension adds another thing that can go wrong—"Claude Code is acting strange" often turns out to be a layer you added yourself. Which is why the isolation work in Chapter 4 comes first.

Summary

  • The criteria are four questions—is asking enough (CLAUDE.md, Skills) / does it have to fire every time (hooks) / do you want it in a separate context (subagents) / do you need to reach outside (MCP). plugins if you are handing it out
  • CLAUDE.md is memory that carries across sessions. Let it grow and the middle sinks, compaction thins it, and the latest instruction beats it. Cut it down and make the priorities explicit
  • hooks are run by the harness, so no judgment enters into it. They can tighten restrictions but not loosen them
  • subagents work in a separate context and return only a summary. Poor fit for sequential work or frequent back-and-forth
  • Skills open only when the description matches: progressive disclosure. Adding more stays cheap, but a vague description never gets called
  • MCP is the standard that widens what it can touch. The status from /mcp decides the move
  • plugins are the distribution box. Someone else's code runs with your privileges, so check the publisher
  • The order to add them starts from the symptom. One at a time, once the problem exists

The more you extend, the more it consumes. Last comes the practice of keeping it running over the long haul. Move on to Chapter 7, Cost and Limits.