Skills, MCP, and hooks
A skill on its own is procedural knowledge — it tells Claude how to do something. In production, that is rarely enough. The skill needs access to your actual tools and data, and you often need guarantees that certain things always happen. That is where MCP and hooks come in. The trick is keeping four mechanisms straight, because they are easy to confuse and they do genuinely different jobs.
Four mechanisms, four jobs
| Mechanism | Job | How it activates | In context |
|---|---|---|---|
| CLAUDE.md | Always-true facts, conventions, rules | Automatically, at startup | Always present |
| Skill | A procedure or workflow (conditional) | You invoke it, or Claude matches its description | Metadata always; body when triggered |
| MCP | Access to external tools, APIs, data | Tools are available for Claude to call | Tool definitions at startup |
| Hook | Deterministic action on an event | Fires automatically on its trigger | Runs regardless of Claude |
The one-line version: CLAUDE.md is facts. A skill is a procedure. MCP is tool access. A hook is enforcement.
Why the distinctions matter
A skill does not grant itself tool access. This is the most common confusion. A skill can say "pull the open issues and summarise them," but it cannot reach your issue tracker on its own. MCP is what connects Claude to that tracker. The skill is the procedure; MCP is the reach. If a skill needs your systems, an MCP connection has to provide them.
A hook is not the model's choice. A skill is conditional — Claude uses it when relevant, and you can stop it. A hook fires every time its event occurs, whether Claude "wants" to or not. That is exactly why hooks are the right tool for things that must always happen: run the formatter on every save, block a commit that fails lint, send a notification when a task finishes. Enforcement belongs in hooks precisely because it is not optional.
Facts belong in CLAUDE.md, not in every skill. If a fact is always true about the project — the architecture, the conventions, the file layout — it belongs in CLAUDE.md, loaded from the start. Skills then rely on it instead of each restating it. This separation keeps both lean, and it is a pattern that holds up in production: skills supply the generic procedure, CLAUDE.md supplies the local truth.
How they compose
The mechanisms are not alternatives; they work together. A single /deploy skill can: rely on CLAUDE.md for the project's deployment conventions, call an MCP-connected tool to trigger the actual deployment, and have a hook fire to run checks or notify the team when it completes. The skill orchestrates the procedure; MCP gives it reach; the hook guarantees the non-negotiable step; CLAUDE.md supplies the standing facts underneath.
A note on a related field you will see: some skills can declare the tools they are pre-approved to use. Treat that as a preview capability — useful, but confirm current support before relying on it in a governed setup.
What comes next
You now have the four mechanisms and how they fit. The next part steps back to the architecture: how skills, CLAUDE.md, and the work loop form one context system, and how to manage the context budget so a skill helps rather than crowds.
Next in this series: Part 3 — Skills and the context architecture