Advice or rule: choosing the right tool

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".

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.

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.