# Advice or rule: choosing the right tool

CLAUDE.md, skills, hooks, subagents and MCP each answer a different question. Pick by asking what must be true, how often it is needed, and what you are willing to carry in context.

## One split explains most of it

Everything you can add to Claude Code falls on one side of a line. Either it is **advice**, which the model reads and weighs, or it is a **rule**, which the harness enforces.

CLAUDE.md is plain markdown read at the start of every session and treated as context, not as enforced configuration. A hook or a deny rule is what guarantees behaviour. If a thing must happen every time, it cannot live on the advice side, however firmly you word it.

Once that split is clear, the choice mostly makes itself.

## Five questions, five tools

**Is it a preference that applies all the time?** Put it in CLAUDE.md. Build commands, naming habits, how you like answers shaped. It is read every session, so keep it short.

**Is it a procedure you need sometimes?** Make it a skill. Only the description sits in context. The body loads when the task calls for it. A release checklist belongs here, not in CLAUDE.md.

**Must it happen every time, with no exceptions?** Write a hook. A formatter after every edit, a type check before Claude may stop. The harness runs it whether or not the model remembers.

**Will the work flood your context with material you only need the conclusion of?** Use a subagent. It works in its own window and returns a summary.

**Does Claude need to reach something outside your machine?** Connect an MCP server, unless a plain CLI such as `gh` already does it, because a CLI costs no context.

## The same job, five ways

Take a concrete wish: "tests must pass before Claude says it is done."

- In CLAUDE.md it is a request. Claude will usually comply, and sometimes not.
- As a skill it becomes a checklist Claude can follow, but only when it is invoked.
- As a `Stop` hook running the tests with `exit 2` on failure, it is a rule. Finishing is blocked until they pass.
- As a subagent, a reviewer can read the failures and report back without filling your session.
- Through MCP, a CI server could be queried, which is only worth it if the results live there.

For the original wish, the hook is the one that matches the word "must".

**Question:** Which tool turns 'always run the type check before finishing' into something that cannot be skipped?

- A line in CLAUDE.md
- A skill with a good description
- A Stop hook that exits with code 2 on failure
- A subagent with a short prompt

**Answer:** A Stop hook that exits with code 2 on failure. Only a hook is enforced by the harness. CLAUDE.md, skills and subagents all depend on the model choosing to follow them.


## What each one costs

Every choice has a price in context or in rigidity.

- **CLAUDE.md** costs context on every session. A long file dilutes its own important lines.
- **Skills** cost their description every turn and the body only when used. A long, rarely useful description is waste.
- **Hooks** cost almost no context, but they are rigid. The advice from the docs is to keep hooks for rules with zero exceptions. If you have forty, most are probably preferences.
- **Subagents** cost a fresh context and a summary round trip, and you lose the detail they did not report.
- **MCP servers** cost tool definitions in context, though tool search loads only names at first, plus any large outputs.
- **Plugins** cost context every turn and run their MCP servers and hooks in every session. A plugin packages the others for sharing. It is not a sixth option for the same job.

> **A promotion path**
Start with advice. When you catch Claude breaking a CLAUDE.md line, ask whether the rule has exceptions. If not, promote it to a hook. If the line is long and only sometimes relevant, demote it to a skill.


## Where each lives

A rough map, so you know where to look when something misbehaves.

- CLAUDE.md files in your home folder, the project and subfolders
- Skills in `.claude/skills/` or `~/.claude/skills/`
- Hooks in `.claude/settings.json` or `.claude/settings.local.json`; commit the shared one for team rules and keep personal overrides in the local file
- Subagents in `.claude/agents/`
- MCP servers in `.mcp.json` for the project, or in your user scope

Settings precedence runs from managed, to the command line, to project local, to shared project, to user. Arrays such as `permissions.allow` merge across scopes.

> **Sort your own list**
Write down five instructions you give Claude repeatedly. Next to each, mark advice, procedure, rule, bulky work, or outside access. Then move each to the tool that matches. Expect at least one to turn out to be a hook.


**Question:** A long migration checklist is needed twice a month. Where should it live?

- CLAUDE.md, so it is always loaded
- A skill, so only its description is in context until needed
- A hook on every edit
- An MCP server

**Answer:** A skill, so only its description is in context until needed. A procedure used sometimes fits a skill: the description stays in context and the body loads only when the task calls for it.