The decision framework

You now know four mechanisms for configuring how Claude works: CLAUDE.md, Skills, MCP, and Hooks. Each one has a different context cost, a different reliability profile, and a different sweet spot.

The skill is knowing which to reach for.

The decision matrix

| Mechanism | Context cost | Reliability | Best for | |-----------|-------------|-------------|----------| | CLAUDE.md | Always loaded (every session) | 100% — always read | Project rules, structure, anti-patterns | | Skills | On-demand (loaded when triggered) | ~50-80% — depends on Claude's judgment | Workflows, checklists, domain knowledge | | MCP | Tool descriptions always loaded | 100% for tool availability | Live data, external service interaction | | Hooks | Zero context cost | 100% — deterministic | Enforcement, automation, quality gates |

Read this table carefully. The two columns that matter most are context cost and reliability. They create a tradeoff that drives every decision.

CLAUDE.md is expensive (always loaded) but reliable (always read). Skills are cheap (on-demand) but less reliable (50-80% trigger rate). MCP is expensive (tool descriptions always loaded) but provides capabilities nothing else can. Hooks are free (zero context) and fully reliable (100% deterministic).

Hooks for enforcement, skills for knowledge

This is the most important distinction in the entire framework.

If something MUST happen every time — lint after every edit, security scan before every push, test run before every commit — use a hook. Hooks execute deterministically. They do not depend on Claude's judgment. They do not consume context. They just run.

If something SHOULD happen when relevant — follow the TDD workflow when writing tests, use the deploy checklist when deploying, apply the database migration pattern when changing schemas — use a skill. Skills encode knowledge and best practices. They guide Claude's behavior but do not enforce it.

I have seen developers put "always run lint before committing" in CLAUDE.md. Claude follows it most of the time. But "most of the time" is not good enough for quality gates. A pre-commit hook runs lint every time, without fail, at zero context cost. The CLAUDE.md line was wasting tokens on something a hook handles better in every dimension.

The decision flowchart

When you have a new piece of configuration to add, run through these questions in order.

1. Does it need real-time data or side effects? If yes, it is MCP. Skills and CLAUDE.md are static text — they cannot query a database or create a pull request. Only MCP provides live interaction with external services.

2. Must it happen 100% of the time? If yes, it is a hook. Not a CLAUDE.md rule, not a skill, not a stern warning in your prompt. A hook. Deterministic execution is the only way to guarantee 100% compliance.

3. Is it needed every session? If yes, it goes in CLAUDE.md. Project structure, dependency rules, import conventions, critical anti-patterns — these apply to every task in every session. They justify the always-loaded context cost.

4. Is it needed occasionally for specific tasks? Then it is a skill. Deployment workflows, testing patterns, migration procedures, domain-specific knowledge — these are on-demand. They cost nothing until triggered.

The layering

These mechanisms are not alternatives. They work together. A well-configured project uses all four in different proportions.

CLAUDE.md defines the rules — what this project is, how it is structured, what patterns to follow. This is the foundation.

Skills provide depth — detailed workflows and domain knowledge that Claude loads when it encounters a matching task. This is the reference library.

MCPs connect the outside world — database access, GitHub integration, live documentation. This is the toolbelt.

Hooks enforce the non-negotiables — quality gates that run every time, regardless of what Claude is doing. This is the safety net.

A concrete example from my own setup: CLAUDE.md says "this project uses TRPC for all API routes — never create REST endpoints." A skill describes "how to create a new TRPC router with proper validation and tests." The Supabase MCP lets Claude query the database to understand the schema. A pre-commit hook runs the type checker to catch any mistakes before they are committed.

Four mechanisms, four layers, one coherent system.

Common mistakes

Putting everything in CLAUDE.md. I see this constantly. CLAUDE.md files that are 300+ lines long, covering every possible workflow and edge case. The result: Claude skims it, misses the important rules buried in the noise, and the context cost is enormous. Keep CLAUDE.md under 100 lines. Move everything else to skills.

Ignoring hooks. Developers write elaborate rules in CLAUDE.md about code quality, then get frustrated when Claude occasionally forgets to lint. A hook would solve this permanently at zero context cost. If you find yourself writing "ALWAYS do X" in CLAUDE.md, that is a hook.

Installing too many MCPs. Every MCP adds tool descriptions to your context budget. Five MCPs with 15 tools each is 75 tool descriptions loaded every session. Audit your MCPs monthly. If you have not used one in the past week, disable it.

Using skills for enforcement. Skills fire 50-80% of the time. That is fine for "follow this workflow." It is not fine for "never push directly to main." Enforcement requires determinism. Determinism requires hooks.

What you have learned in this chapter

Context is the fundamental constraint. Everything flows from that.

You manage context through four mechanisms — each with a different cost and reliability profile. CLAUDE.md for always-on rules. Skills for on-demand knowledge. MCPs for live tool access. Hooks for deterministic enforcement.

You control cost through model routing — Sonnet as default, Opus for deep reasoning, Haiku for subagent work. Thinking caps prevent runaway deliberation. Early compaction keeps context clean.

In the next chapter, we build the feedback loop — the system that turns friction into improvement and makes your setup get better with every session.