---
title: "CLAUDE.md vs Skills vs Hooks vs Subagents"
description: "Where each rule belongs in Claude Code: CLAUDE.md for what Claude must always know, skills on demand, hooks to enforce, subagents to isolate. A guide for PMs."
canonical_url: "https://builderscamp.com/guides/tools/claude-md-vs-skills-vs-hooks-vs-subagents"
date_published: "2026-09-27"
date_modified: "2026-09-27"
author: "Andre Albuquerque, Guilherme Salgueiro"
publisher: "Builders Camp"
guide_class: "tools"
---

# Claude Code CLAUDE.md vs skills vs hooks vs subagents: where each rule belongs

**TL;DR:** Put a rule in CLAUDE.md if Claude must always know it, in a skill if it is needed only for some tasks, in a hook if it must hold every time without exception, and in a subagent if the work would flood your conversation. Anthropic's own rule of thumb keeps CLAUDE.md under 200 lines, and a rule that keeps being ignored moves up a level: from CLAUDE.md to a hook, then to a CI check.

## Which Claude Code surface should hold this rule?

Ask one question per surface, in order, and stop at the first yes. Anthropic's [Extend Claude Code](https://code.claude.com/docs/en/features-overview) page gives the first test in a single sentence: "Put it in CLAUDE.md if Claude should always know it." The same page sets the size limit as a rule of thumb of under 200 lines for CLAUDE.md, and says to move reference content into skills once it grows past that. The other three surfaces answer the questions CLAUDE.md cannot.

| Question about the rule or task | If yes, it belongs in | Loads or runs | Context cost |
|---|---|---|---|
| Must Claude know this in every session? | CLAUDE.md | Every session, automatically | Every line, every session |
| Is it a procedure or reference needed only for some tasks? | A skill | On demand, by name or by matching its description | The description every session, the body only when used |
| Must it hold every time, whatever the model decides? | A hook | At a lifecycle event, such as before a tool call | None unless the hook returns output |
| Would the work flood your conversation with material you will not reread? | A subagent | In its own context window, returning a summary | Only the summary |

The context column is the one product managers tend to skip, and it matters more than it looks. Everything in CLAUDE.md competes for attention with the task in front of Claude, every session, whether or not it is relevant. A 600-line CLAUDE.md is not three times as helpful as a 200-line one. It is a longer list the model has to weigh before it gets to your question.

## When does a rule belong in CLAUDE.md?

When it is true of the project every time, whoever is asking and whatever the task. The company's product names and their exact spelling. Where the source-of-truth roadmap lives. The command that builds the prototype. "Never commit customer data to this repository." Those facts do not change between a pricing analysis and a launch email, so paying their context cost every session is worth it.

Anthropic's [memory documentation](https://code.claude.com/docs/en/memory) says Claude treats CLAUDE.md "as context, not enforced configuration", and that specific, concise instructions are followed more consistently. Two consequences follow for a product team. Write each rule as one concrete sentence, not a paragraph of reasoning. And accept that a CLAUDE.md rule is a strong default, not a guarantee. Our guide to [writing a CLAUDE.md file as a product manager](https://builderscamp.com/guides/tools/claude-md-for-product-managers) covers what to put in the file and what to leave out.

## When does a rule belong in a skill?

When it is a procedure you would otherwise paste into chat, or reference material that matters for one kind of task. A competitor teardown checklist. The format your team uses for release notes. The eight questions you ask before accepting an analytics claim. None of those help Claude write a customer email, so none of them should load when it does.

A skill is a folder with a `SKILL.md` file whose description tells Claude when to use it. You can call it by name with a slash command, or Claude loads it when the task matches the description, according to the [skills documentation](https://code.claude.com/docs/en/skills). That second route is why the description matters more than the body: a vague description means the skill either never loads or loads for the wrong task. [Claude Code skills for product managers](https://builderscamp.com/guides/tools/claude-code-skills-for-product-managers) walks through writing one, and the glossary entry on the [AI agent skill](https://builderscamp.com/guides/glossary/ai-agent-skill) covers the concept.

## When does a rule belong in a hook?

When a single violation is expensive or cannot be undone, or when the rule has already been ignored in CLAUDE.md. A hook is a command Claude Code runs itself at a lifecycle event. The [hooks reference](https://code.claude.com/docs/en/hooks) documents `PreToolUse` as the event that runs before a tool call, and a hook there that exits with code 2 blocks the call. The model is not consulted.

For a product manager, the usual candidates are few and specific: a folder of signed-off specs nobody should rewrite, a credentials file, a pricing configuration that goes to production. Hooks can also add context rather than block, such as printing this quarter's priorities at the start of every session. Our guide to [Claude Code hooks](https://builderscamp.com/guides/tools/claude-code-hooks-for-product-workflows) builds both kinds. The trade-off is that a hook has no judgment. It can stop an edit to a path, and it cannot tell whether a spec is any good.

## When does work belong in a subagent?

When a task would fill your conversation with material you will not look at again. The [subagents documentation](https://code.claude.com/docs/en/sub-agents) describes each subagent as running "in its own context window with a custom system prompt, specific tool access, and independent permissions", and returning a summary to the main conversation. Reading 60 interview transcripts to find the recurring objections is a subagent task. So is a sweep of every open ticket that mentions onboarding.

Subagents also give you role separation. A reviewer subagent that did not write the draft has no stake in defending it, and you can restrict it to read-only tools so it cannot fix what it is meant to judge. The subagents documentation warns that descriptions for your custom subagents cost context too, and shows a startup warning once their combined descriptions pass 15,000 tokens. [Claude Code subagents for PM workflows](https://builderscamp.com/guides/tools/claude-code-subagents-for-pm-workflows) shows three worth setting up.

## What happens when a rule keeps being ignored?

Move it up a level instead of rewriting it louder. The sequence is the same every time:

1. **CLAUDE.md.** Write the rule as one short, specific sentence. If it slips once, tighten the wording.
2. **Hook.** If it slips again, or a single slip would be expensive, enforce it with a `PreToolUse` hook that blocks the action and explains why on stderr.
3. **CI check.** If the rule has to hold for every person and tool that touches the repository, not just your Claude Code session, run it as a check on every pull request.

Each step up costs more to set up and gives you less flexibility, which is why you climb only when the level below has failed. Adding capital letters and "IMPORTANT" to a CLAUDE.md rule that has been ignored twice is the most common way to avoid making that decision. The model already read the rule. Rewording it rarely changes the outcome as much as moving it does.

## A worked example: where six product rules end up

Here is one product team's list, sorted with the four questions. The examples are ours, and the routing is the point.

| Rule or task | Where it goes | Why |
|---|---|---|
| "Our plan names are Starter, Team and Scale, always capitalised" | CLAUDE.md | True in every session, one line |
| The competitor teardown procedure, with its twelve checks | Skill | Needed a few times a month, too long to load every session |
| "Never edit anything under specs/approved/" | Hook | One slip rewrites a signed-off decision |
| Summarise 60 interview transcripts into recurring objections | Subagent | Would flood the conversation with raw notes |
| Read this week's tickets from the tracker | MCP server | A question of access, not of instructions |
| Give the growth team the same setup | Plugin | Packaging the skills and hooks above for a second repository |

The last two rows are there because they are the usual source of confusion. [MCP](https://builderscamp.com/guides/tools/mcp-for-product-managers) decides what Claude can reach, and a [plugin](https://builderscamp.com/guides/tools/claude-code-plugins-for-product-managers) decides how a setup travels between repositories. Neither decides what Claude should know or do, which is what the four questions above are about.

## Is this setup worth it for a product manager?

For most product managers, only part of it. The honest objection to a guide like this one is that it makes a four-part system sound necessary when a short CLAUDE.md and two skills cover most product work. That objection is right. Anthropic's own [Extend Claude Code](https://code.claude.com/docs/en/features-overview) page suggests starting with CLAUDE.md and adding other extensions as specific triggers come up, such as a correction you have made twice or a playbook you have pasted three times.

What the four questions give you is not a reason to build everything. They give you a place to put the next rule when it arrives, so it does not end up in CLAUDE.md by default, which is how the file grows past 200 lines and stops working.

## Where does Builders Camp teach this?

Building with Claude Code, taught by Guilherme Salgueiro across 2 live sessions, lists CLAUDE.md and context architecture; skills, agents and memory; MCP and tool integrations; multi-agent orchestration; and hooks, CI/CD and quality gates among its public learning topics. Its practical challenge asks you to write a project CLAUDE.md, design a small agent architecture with explicit boundaries, and specify one hook as part of a governance layer. New to Claude Code? Claude Code for Product Managers, taught by Andre Albuquerque across 2 live sessions, is the starting point the catalogue recommends.

[See the Building with Claude Code bootcamp](https://builderscamp.com/bootcamps/building-with-claude-code?utm_source=guide&utm_medium=organic&utm_campaign=claude-md-vs-skills-vs-hooks-vs-subagents)

For the layer underneath all four surfaces, the glossary entry on [context architecture](https://builderscamp.com/guides/glossary/context-architecture) covers how to decide what Claude sees and when.

## Frequently asked questions

### What is the difference between CLAUDE.md and a skill?

CLAUDE.md loads into every session automatically, so it suits facts and rules Claude should always know. A skill loads on demand, when you type its name or when Claude matches its description to the task, so it suits procedures and reference material needed only sometimes. Only the skill's short description costs context every session.

### What is the difference between a skill and a hook?

A skill is instructions Claude reads and interprets, so the outcome can vary. A hook is a command Claude Code runs itself at a lifecycle event, such as before a tool call, so it fires every time its matcher matches. Use a skill when the task needs reasoning and a hook when it must happen the same way every time.

### When should I use a subagent instead of a skill?

When the work would flood your main conversation: reading dozens of files, a long search, a large set of interview notes. A subagent runs in its own context window and returns only a summary. A skill adds its content to your current conversation, which is what you want for a checklist and not what you want for a 400-file search.

### Do I need all four as a product manager?

No. Most product repositories run well on a short CLAUDE.md and two or three skills. Add a hook when a rule has been ignored twice or a single slip would be expensive, and a subagent when a recurring task keeps filling your context. Anthropic's own docs describe adding features as specific triggers come up.

### Can a rule in CLAUDE.md be enforced?

Not by CLAUDE.md itself. Anthropic's memory documentation says Claude treats CLAUDE.md and auto memory as context, not enforced configuration. To block an action regardless of what Claude decides, the documentation points to a PreToolUse hook, which blocks the tool call when it exits with code 2.

### Where do MCP and plugins fit?

MCP connects Claude to an outside system such as a ticket tracker or analytics tool, so it answers a different question: what can Claude reach, rather than what should it know or do. Plugins are packaging: a plugin bundles skills, hooks, subagents and MCP servers so a second repository or team can install the same setup in one step.

### How long should CLAUDE.md be?

Anthropic's rule of thumb is under 200 lines. When it grows past that, move reference material into skills or split it into .claude/rules/ files, which can be scoped to file paths so they load only when Claude works on matching files.

## Sources

- [Claude Code docs: Extend Claude Code](https://code.claude.com/docs/en/features-overview)
- [Claude Code docs: How Claude remembers your project](https://code.claude.com/docs/en/memory)
- [Claude Code docs: Create custom subagents](https://code.claude.com/docs/en/sub-agents)
- [Claude Code docs: Hooks reference](https://code.claude.com/docs/en/hooks)
- [Claude Code docs: Skills](https://code.claude.com/docs/en/skills)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.