Choosing Features: CLAUDE.md vs Skill vs Hook vs MCP vs Subagent
📚 Series Navigation: The previous post 29 Agent teams taught you how to use Agent teams for multi-agent parallel collaboration. This post wraps up the entire fourth group — learning CLAUDE.md, Skill, Hook, MCP, and Subagent all at once can make it easy to choose the wrong one when they are all crammed into your head. I will give you a decision table and a decision tree, just check "which one to use" directly against your "requirements", and you will never struggle again.
Brothers, having learned up to here, you have accumulated a bunch of extension points in your hands.
CLAUDE.md, Skill, Hook, MCP, Subagent, plus the ubiquitous slash command, five or six nouns, each makes sense individually. But when it actually comes to "which one should I use for my requirement", nine times out of ten you will get stuck. The most common questions from people who have just finished learning this suite are "Should I use a Skill or a Subagent for this?" and "Can I write this into CLAUDE.md?"
To be blunt, this is not a lack of knowledge, it is a failure to establish a "requirement → solution" mapping. You have read the official introduction for each extension point, but they are organized by "what this is", not by "what you want to do". This post reverses that — starting from your requirement, deducing which one to use.
Let's put it this way: the previous nine posts handed you five weapons one by one, and this post teaches you which one to draw in battle.
After reading this post, you will get:
- A one-sentence positioning of what the five major extension points (plus slash command) each "solves, when to choose them, and when not to use them"
- A "requirement → recommended solution" decision table to look up solutions based on symptoms
- A decision tree you can follow, asking three or four questions to lock in which one to use
- Several sets of the most easily confused comparisons (Skill vs Subagent, CLAUDE.md vs Skill, Hook vs permission rules) explained thoroughly at once
- Knowing how these extension points can be combined and packed to go using plugins
01 First, Build a General Framework: Six Extension Points Inserted at Different Positions in the "Agent Loop"
Before you start picking, set up a general framework in your head. These extension points are not six parallel options, but rather six hooks inserted at different stages of the Claude workflow.
Recall the "agent loop" mentioned in post 03 — Claude works by looping "think → act → observe". These six extension points (CLAUDE.md, Skill, slash command, MCP, Subagent, Hook) perfectly plug into different parts of this loop: some stuff background in before "think", some connect externally or create clones during "act", and some automatically pull the trigger at a fixed moment. The official statement points this out very accurately and is worth remembering first:
Extensions plug into different parts of the agent loop.
Analogy: A hospital triage desk. When you feel unwell and go to the hospital, you don't rush into a department yourself; you first go to the triage desk and state your "symptoms" — headache goes to neurology, stomachache goes to gastroenterology, needing an X-ray goes to imaging. The triage desk doesn't treat illnesses; what it does is direct you to the right department based on your symptoms. In this post, I am acting as this triage desk for you: you report your "requirement", and I will direct you to the right "extension point".
Down to real scenarios, the things you struggle with are usually just a few phrases: "I want it to always follow a certain rule," "Let it automatically pull up a certain expertise when needed," "Make something automatically happen at a specific time," "Let it connect to external data or services." Once the requirement is clear, which department to register for is actually not that hard. In the following sections, I'll explain the "departments" one by one, and finally give you a master table plus a tree.
💡 One-sentence summary: The six extension points are not six parallel options to choose from, but hooks inserted at different stages of "think → act → observe"; the key to choosing is not "which one is more powerful", but "which hook your requirement should hang on".
02 Six Departments, Recognizing Each One's "Primary Indication" in One Sentence
First, let's nail down the "primary indication scope" of the six extension points in one sentence. This section is the foundation, and the decision table below is built entirely on it. Following the tone of the official feature table, I'll pair each with its most typical scenario.
CLAUDE.md —— Rules you want it to "always remember". Project conventions, build commands, "always use pnpm instead of npm", "run tests before committing" and similar always-active context. It loads automatically for every session, so Claude sees it as soon as it starts working.
Skill —— Specialized capabilities you want it to "automatically pull up when needed". Reusable knowledge or processes: an API style guide, a deployment checklist, a debugging routine. Normally, it only occupies the description text, the full content is only pulled in when used; you can also actively call it with /<name>.
slash command —— Fixed processes you "actively trigger with one click". It's actually a usage of Skill (the kind triggered with /<name>). The only difference is "who initiates it": a Skill can be automatically judged by Claude whether to use it, whereas a slash command is when you type /deploy to actively call it.
MCP —— An interface to "connect it to the external world". Querying your database, sending messages to Slack, controlling the browser — anything Claude's built-in tools can't reach and needs to connect to external services or data, relies on MCP (see post 22 for details).
Subagent —— Spawning an "independent clone" for it to do the dirty work. When it needs to read dozens of files or run large-scale searches, but you only want a conclusion and don't want the intermediate process to clutter the main conversation, send a Subagent (see post 23 for details). It works in an isolated context and only hands back a summary when done.
Hook —— "Automatically pulling the trigger" at a fixed timing. A Hook is simply "a piece of action that runs automatically as soon as a certain event happens." Once a lifecycle event triggers (like "every time a file is modified" or "every time a session starts"), it executes without fail — running a linter, rejecting a dangerous command, sending a notification. It doesn't rely on Claude thinking; the trigger is guaranteed.
The concept of Hook hasn't been focused on previously, so just establish an impression here: It is an "event-triggered automatic action". The complete syntax and which events can be listened to will be broken down specifically in post 33.
It's easy to get confused just talking about it; putting a table side by side makes it immediately clear when compared:
| Extension Point | One-Sentence Primary Indication | Who Triggers It | Does it Occupy Resident Context? |
|---|---|---|---|
| CLAUDE.md | Project rules to always follow | Automatic, loads per session | Yes (full text resident) |
| Skill | Specialized knowledge / processes pulled up on demand | Claude judges automatically OR you /<name> | Low (normally only description occupies it) |
| slash command | Fixed processes actively triggered with one click | You type /xxx | Low (same as Skill) |
| MCP | Connect to external services / data | When Claude uses the tool | Low (initially only tool name occupies it) |
| Subagent | Isolated context / parallel specialized tasks | You or Claude assigns work | Does not occupy main window (independent context) |
| Hook | Automatically run fixed actions at specific events | Lifecycle events | Zero (unless it returns output) |
You don't need to memorize this table, but the "Who Triggers It" and "Does it Occupy Resident Context" columns are the watershed for all subsequent decisions — one determines "whether it's you active or it automatic", and the other determines "whether it's worth keeping open".
💡 One-sentence summary: The "primary indications" of the six extension points are different — rules go into CLAUDE.md, expertise into Skill, one-click processes are slash commands, external connections rely on MCP, isolated work dispatches a Subagent, and automatically running at fixed timings uses Hook.
03 Decision Table: Report Requirement, Look Up Solution
With the general framework in place and the primary indications recognized, now for the core of this post — the "Requirement → Recommended Solution" decision table. The usage is very simple: find the requirement in the left column that most closely matches what's in your mind, the right column is the extension point you should use, and the last column tells you "why it is the one, and don't mistakenly use the one next door".
| Your Requirement (the phrase in your mind) | Recommended Solution | Why It Is / Don't Use Wrongly |
|---|---|---|
| "Always follow our conventions every time" (use pnpm, run tests before committing) | CLAUDE.md | Always-active rules, you want it to see them every session |
| "This API doc / style guide, it can look up when needed" | Skill | Reference material, don't occupy context normally, pull in when used |
"I want to type /deploy and run the entire deployment process" | slash command (a type of Skill) | Fixed multi-step process actively triggered by you |
| "Let it query our company database / send to Slack" | MCP | Needs to connect to external services and data, built-in tools can't reach |
| "Let it read dozens of files and just give me a conclusion" | Subagent | Needs context isolation, don't let intermediate processes flood the main window |
| "Check these things simultaneously, independent of each other" | Subagent (multiple in parallel) | Parallel specialized tasks, each works independently and returns a summary |
| "Every time a file is modified, automatically run ESLint" | Hook (PostToolUse) | Automatic action at a fixed time, doesn't need it to think |
"Commands like rm -rf /, forcibly block them for me" | Hook (PreToolUse) or Permission Rules | Needs to "guarantee" blocking, can't rely on prompts |
| "It keeps forgetting a certain convention, reminded it twice already" | CLAUDE.md | Repeated mistakes go into resident rules, not temporary correction in chat |
| "The same opening prompt, I type it manually every day" | Skill | Repeatedly input prompts, saved as a callable Skill |
| "This set of configs, I want to move exactly to another project" | Plugin (packaging layer) | Bundle Skill / Hook / Subagent / MCP together and take them away |
I've also incorporated the spirit of the official "build your setup over time" trigger table into this: Many requirements are actually forced by "repetition" — typing the same prompt for the third time, correcting the same mistake for the second time; these are signals that it's time to "solidify" it into the corresponding extension point, stop relying on on-the-spot instructions.
Here's an interjection about the most common real pitfall to step into. If you want to save effort, it's very easy to stuff a nearly 300-line API endpoint list directly into CLAUDE.md, thinking "how convenient for it to always remember it". The result? — Every time a session starts, it first swallows up a huge chunk of context; before proper work has even begun, a chunk of the workbench is taken away. Even worse, Claude often fails to grasp the few core conventions you truly emphasized, getting drowned in that pile of API details. Moving the API list into a Skill, and leaving only one sentence in CLAUDE.md: "See api-skill for API specifications", the world instantly becomes peaceful. This is the rule the official docs repeatedly mumble about:
Keep CLAUDE.md under 200 lines. If it's growing, move reference content to skills.
💡 One-sentence summary: When in doubt, first translate the requirement into the "phrase in your mind", then take a seat at this table; especially remember "always active → CLAUDE.md, reference on demand → Skill, external connection → MCP, isolated work → Subagent, fixed timing → Hook".
04 A Decision Tree: Down to Three or Four Questions, Direct Lock-in
The table is "lookup solution for known requirement", but sometimes you haven't thought your requirement too clearly yourself. This is when a decision tree is smoother — follow a few either-or questions down, and when you reach a leaf, it's the answer.
I designed the judgment sequence as the tree below. The core is just four questions; ask them in this order, and you basically won't go wrong:
This image breaks down "I have a requirement, which extension point should I use" into a top-down Q&A path — first asking "does it need hard guarantees / external connections?", then asking "should it be automatic or your active?", branching all the way down, each leaf node is a clear extension point.
Walking through this tree in text, you'll find the judgment sequence is actually very natural:
Question 1: Does this task need to "connect to external services or data"? Yes — like querying a database, sending Slack messages, controlling the browser — directly hook up MCP, end of story. This is the easiest to recognize and should be filtered out first.
Question 2: Does this task need to be "always true, cannot rely on Claude's self-awareness"? Requires a "guaranteed" level of enforcement — like ".env is absolutely not allowed to be edited", "rm -rf / must be blocked", "must run lint after every file modification" — use Hook (or permission rules, see the next section). The keyword is "guarantee": A Hook will always trigger on its event, it is deterministic; writing it in CLAUDE.md is just a "request", Claude might comply or might miss it.
Question 3: Is this task a "one-off dirty work, want it isolated"? Needs to read a bunch of files, run large searches, only want a conclusion, don't want the process to fill up the main conversation, or want several things in parallel — dispatch a Subagent. It works in an independent context and only hands back a summary when done.
If it hasn't branched out by here, it's a choice between "knowledge / rule / process", ask the final one:
Question 4: Should it "always be seen" or "only seen when needed"?
- Rules that must be seen every time (conventions, build commands, never do X) → CLAUDE.md.
- Knowledge or processes only looked up when needed (API docs, deployment checklists, debugging routines) → Skill.
- Within this, if it's a "multi-step process you want to actively trigger with one click", just give this Skill a
/<name>and use it as a slash command.
Four questions, from the "easiest to recognize external connection" down to the "most subtle knowledge vs rules", filtering down layer by layer, the leaf is the answer. When picking extension points, basically just silently recite these four sentences in your head.
💡 One-sentence summary: The order of the decision tree is "Connect external? → Need hard guarantee? → Need isolation? → Read every time or on demand?". After four questions, you reach the leaf directly; it's much more useful than memorizing a bunch of definitions.
05 Three Most Easily Confused Sets, Explained Thoroughly at Once
Just having a tree is not enough; there are always a few pairs that look similar and make you struggle when choosing. I've picked out the three groups beginners ask about the most and will break them down one by one. Only when these three groups are explained clearly will the decision table not conflict when you use it.
Skill vs Subagent
These two are the easiest to confuse, because "both can hold a set of processes". But what they solve is not the same thing at all.
Analogy: Manual vs Dispatch. A Skill is a shareable manual, whoever needs it flips through it, and the content you read goes into your current "work notebook"; a Subagent is dispatching a person out with a task, and they only come back to report the conclusion to you when done, you are completely untouched by how much reference material they flipped through outside.
The core difference is one word: Context.
| Comparison Dimension | Skill | Subagent |
|---|---|---|
| What is it | Reusable knowledge / processes | Isolated worker with independent context |
| Where does content go | Loaded into your main window | Uses its own window, only results return to main window |
| Is main conversation affected | Occupies main context | Isolated, hardly occupies main window |
| Best suited for | Reference materials, callable processes | Reading a bunch of files, parallel tasks, specialized workers |
Cut it in one sentence: Choose Skill if you want "content to come into my space to be used", choose Subagent if you want "the process not to pollute my space, just give me the conclusion". They can also combine — a Subagent can preload a specific Skill when it starts, which is equivalent to "the dispatched person bringing their own dedicated manual".
CLAUDE.md vs Skill
Both are "storing instructions", the difference lies in the loading method.
| Comparison Dimension | CLAUDE.md | Skill |
|---|---|---|
| When is it loaded | Every session, automatically | On demand (loaded only when used) |
| Can it trigger workflows | No | Yes, using /<name> |
| Best suited for | Rules to "always do X" | Reference materials, callable processes |
The official judgment mantra is very straightforward: What "Claude should always know" goes into CLAUDE.md, what "is only sometimes needed to be looked up" goes into Skill. The pitfall in Section 03 of "stuffing 300 lines of APIs into CLAUDE.md" is essentially mistakenly putting what should go into Skill into CLAUDE.md.
Hook vs Permission Rules
The struggle with this group is: Should I use a Hook or permission rules (the deny discussed in post 20) to "block a certain dangerous operation"?
First, the commonality: Both are "mandatory" hard constraints, not relying on Claude's self-awareness — on this point they stand on the same side, clearly distinct from "requests written in CLAUDE.md". The official sentence hits the nail on the head:
Instructions like "never edit
.env" in CLAUDE.md or a skill are requests, not guarantees. APreToolUsehook preventing the edit is enforcement.
The difference lies in "how broad the scope is, and how complex the action is":
- Permission Rules: Declarative, specifically manages "is this tool / command allowed or not". Writing a
Bash(rm -rf *)rule in the deny rules (i.e."deny": ["Bash(rm -rf *)"]in settings.json) blocks it dead; it's concise, suitable for pure "admission judgment". - Hook: Can run a script, and besides "blocking", it can conveniently do something else — while blocking, log it, send a notification, or automatically rewrite arguments. Suitable for "blocking + attached actions" or complex judgments that permission rules cannot express.
A handy rule of thumb: For black-and-white judgments like "allowed or not", prioritize using permission rules, done in one line; if you need to do something at the moment of blocking (logging, notifying, rewriting), then step up to Hook. The two don't conflict and are often used together — permission rules set the baseline, Hook patches those tasks of "blocking and then having to do something else".
💡 One-sentence summary: Skill enters my context / Subagent isolates and only gives conclusion; CLAUDE.md read every time / Skill read on demand; permission rules manage "allowed or not" black-and-white judgment / Hook manages "blocking + attached actions" — distinguish the three groups, and choices will no longer clash.
06 Combination is the Norm: After Doing Single-Choice Questions for a Long Time, Remember They Can Stack
Up to here, you might think picking extension points is a "single-choice question". On the contrary — real projects are almost all combinations. Each extension point does what it's best at, and pieced together they form a complete set of "equipment".
Several classic pairings given officially; I will translate each group with real scenarios:
| Combination | How They Cooperate | What It Looks Like In Practice |
|---|---|---|
| Skill + MCP | MCP is responsible for "connecting", Skill is responsible for "teaching it how to use it well" | MCP connects to the database, Skill writes out your table structure and common query routines clearly |
| Skill + Subagent | Start a Subagent inside a Skill to do work in parallel | An /audit Skill simultaneously dispatches three Subagents to check security, performance, and style |
| CLAUDE.md + Skill | CLAUDE.md holds resident rules, Skill holds on-demand details | CLAUDE.md writes "Follow our API conventions", Skill contains that full style guide |
| Hook + MCP | Hook uses MCP to do an external thing when a certain event triggers | After modifying a critical file, Hook automatically sends a Slack notification via MCP |
Looking at the "Skill + MCP" group makes the beauty of combinations clear: With only MCP, Claude can connect to the database, but it doesn't know how your tables are designed or how to query them optimally; with only Skill, it knows the routines but can't connect to the DB. Stacking the two is "both connecting and using well". A common setup is built exactly like this — MCP hooks up the DB, Skill is full of "which table to query for user orders, which field is the statistical dimension", and the queries Claude writes based on this basically don't need rework.
Then, how do you move a well-combined set of configurations to another project, or share it with colleagues? The answer is Plugin — it is the layer that "packages all this to go".
Analogy: A Suitcase. When you go out, you don't carry your shirts, shaver, and chargers one by one in your arms; you pack them all into a suitcase and carry it away. A Plugin is this suitcase — bundling Skills, Hooks, Subagents, and MCP servers all into one installable unit. When a second project needs to use the same set, installing this plugin completes everything; the Skills inside even have namespaces (like /my-plugin:review), so multiple plugins installed separately won't have name collisions. The official text says it very directly:
Plugins bundle skills, hooks, subagents, and MCP servers into a single installable unit.
The specific method for Plugins was covered in post 24; here you just need to remember its position in the system: the other five are "features", plugin is the layer that "boxes up features for distribution".
💡 One-sentence summary: Picking extension points is not a single-choice question — real configurations are almost always combinations (Skill+MCP, CLAUDE.md+Skill...); if you want to move a whole set elsewhere or share it, use Plugin to pack it into a box and take it away.
07 Hands-on: "Triage" a Real Requirement List Item by Item
Just looking at the table doesn't count as knowing it; you have to actually "triage" it once. Below is a simulated list of real requirements — these are real thoughts that pop up in projects. Your task: follow the decision tree earlier and register each item to the right department. You don't need to type commands for this section, it's purely mental practice, but it's more effective than memorizing ten definitions.
Step 1: Copy this list to your notes (or just run it in your head)
Requirement List (pick one extension point for each):
A. The team convention is "always use pnpm, npm is forbidden"; want it to comply every time.
B. Want to let it query the company's internal PostgreSQL database.
C. Want to type one command to run the whole release process: "tag → modify changelog → push".
D. Every time it finishes editing any file, automatically run prettier to format.
E. Let it read the entire utils directory at once, only tell me which functions are unused.
F. A very long "Internal Error Code Mapping Table", it needs to look it up occasionally.
G. "Migration scripts for production databases are absolutely not allowed to be executed by it", must forcibly block.Step 2: Go through the decision tree yourself first, and write the answer after each item
Don't rush to look down; first use the four questions in Section 04 (Connect external? Need hard guarantee? Need isolation? Read every time or on demand?) to judge yourself.
Step 3: Check the answers
Below are the reference answers and reasons for judgment. How many you got right is not important; what matters is "why" they match:
| Requirement | Should Use | Reason for Judgment (Which path on the decision tree) |
|---|---|---|
| A Always use pnpm | CLAUDE.md | Doesn't connect externally, doesn't need script guarantee, doesn't isolate; is a "see every time" rule |
| B Query internal DB | MCP | Hits on the first question: needs to connect to external services and data |
| C One-click release | slash command | Fixed multi-step process actively triggered by you, give a Skill a /release |
| D Auto-format after editing | Hook (PostToolUse) | Fixed timing, needs to run every time, doesn't need it to think |
| E Read whole dir for dead code | Subagent | Read a bunch of files just for a conclusion, isolate to avoid flooding main conversation |
| F Occasionally check error codes | Skill | Reference material read only on demand, don't stuff in CLAUDE.md |
| G Ban executing migration scripts | Permission Rules / Hook | Need to "guarantee" blocking, can't rely on prompts; pure admission judgment prioritizes permission rules |
Expectation: If you didn't mix up A and F (one into CLAUDE.md, one into Skill), didn't mix up D and G (one Hook runs automatically, one permission blocks dead), and for E you chose Subagent instead of Skill — then your "triage" logic is already established, and when real requirements come in the future, just follow this process.
If you got stuck on any item, go back to Section 05 and flip to the corresponding set of comparisons; most likely you haven't distinguished that pair clearly. This set of judgments usually takes a while to practice to build muscle memory — the first few times it's easy to "forcefully stuff Subagent's work into a Skill", and after running it twice and finding the main conversation flooded with intermediate processes, you'll remember "if you just want a conclusion, dispatch a clone".
💡 One-sentence summary: Taking a real requirement list to triage item by item through the decision tree is a hundred times more useful than memorizing definitions; if stuck on an item, going back to read the corresponding "easily confused comparison" will basically clear it up.
08 Summary
This post wraps up the fourth group — flipping the five major extension points (plus slash command) you've learned along the way from "what each is" to "which one to use when a requirement comes".
Stringing the core together to review:
| The phrase in your mind | Department to register | One-sentence key point |
|---|---|---|
| "Must follow every time" | CLAUDE.md | Always-active rules, loads automatically per session, keep under 200 lines |
| "Automatically pull up when needed / I trigger with one click" | Skill / slash command | On-demand knowledge and processes, normally doesn't occupy context |
| "Connect external services and data" | MCP | What built-in tools can't reach, relies on it to connect externally |
| "Read a bunch of files and only give me a conclusion" | Subagent | Isolated context, parallel specialization, only returns a summary |
| "Automatically run at specific timing, needs guarantee" | Hook | Deterministic actions triggered by events, guardrail-level enforcement |
| "Move the whole set away / share with others" | Plugin | Bundle the above into one installable unit |
You should now be able to: Take any "I want Claude to..." requirement and no longer get confused by five or six nouns — silently recite those four questions in your mind (Connect external? Need hard guarantee? Need isolation? Read every time or on demand?), follow the decision tree to the leaf, and directly lock in which one to use. When encountering easily confused pairs like Skill vs Subagent, CLAUDE.md vs Skill, or Hook vs permission rules, you can clearly explain the exact differences between them. Once this "requirement → solution" mapping is established, the parts you learned in the previous nine posts will be truly activated and can be used on demand.
The entire fourth group (Advanced Feature Extensions) is now complete. You have touched all five weapons, and know which one to draw in battle — what's left is just to use them smoothly.
Starting from the next post, we enter the fifth group "System Configuration and Optimization". Kicking off with 31 "settings.json: User-level / Project-level Configuration" — along the way you've written CLAUDE.md, configured permissions, and will soon configure Hooks. It's time to properly settle which file these configs should be written into, and who overwrites whom between user-level and project-level. Think about it: the same config, written in your home directory versus in the project, might have exactly opposite effects — the intricacies inside this will be clarified for you in the next post.