Four things Claude Code gives you show up over and over in the docs — CLAUDE.md, hooks, skills, plugins — and they're easy to confuse. They sound adjacent. They sometimes live in the same directory. They each make Claude behave differently, for different reasons, at different moments in a turn.

This piece lays each one out, shows where it fits in the lifecycle, and gives you a quick way to decide which one to reach for. By the end, "should this be a hook or a skill?" should answer itself.

CLAUDE.md — the thing that's always there

CLAUDE.md is passive context. It's a Markdown file Claude Code auto-loads into the conversation. You write it; nobody runs it. Every prompt, every turn, it's sitting there.

It answers the question "what should Claude assume about this project before I even say anything?" Stack choices, house rules, the name of the canonical db pool, the fact that you use vitest not jest. Stable facts.

There are three scopes: project-level (in the repo), user-level (your home directory), and enterprise-level (org-wide). They stack — more specific overrides more general.

CLAUDE.md is the only one of the four that Claude cannot choose to ignore. The harness puts it in the context window, period.

Hooks — the deterministic harness layer

Hooks are shell commands the harness runs on lifecycle events. They are not code the model writes; they're entries you put in settings.json that fire when something specific happens.

The event taxonomy includes UserPromptSubmit, PreToolUse, PostToolUse, Stop, SessionStart, and a handful of others. Each can take a matcher (which tool? which file?) and a command. The command's exit code and stdout can block the action, append context to the turn, or just run quietly.

Use hooks for "I want X to happen without Claude deciding to do it." Formatting on save. Secret redaction before submit. A notification when the turn ends. Running your test suite after every edit.

Skills — capabilities the model reaches for

Skills are on-demand, model-invoked packages. Each one lives in a folder with a SKILL.md: frontmatter declaring name and description, plus body instructions the model reads when it decides to use the skill.

The key word is decides. Unlike CLAUDE.md (always loaded) and hooks (harness-triggered), a skill is surfaced to the model as available, and the model picks it up when the description matches the task. Because the full content only loads on invocation, skills can be long and specific without bloating every turn.

Think of them as specialized playbooks. A frontend-design skill. A migration-review skill. A skill that knows your company's release notes template. The SKILL.md can reference helper scripts, prompt templates, and reference docs — all loaded lazily.

Plugins — the distribution layer

Plugins are bundles. A plugin is a packaged directory that can contain any mix of skills, subagents, slash commands, hooks, and MCP server definitions. It has a .claude-plugin/plugin.json manifest, it's installable from a marketplace, and it's the only one of these four concepts that isn't itself a runtime primitive.

You reach for a plugin when you want teammates to install the same toolkit with a single command, or when you want to publish something for the wider community. "Our engineering plugin" could bundle the migration-review skill, a hook that runs typecheck after edits, a release-notes subagent, and a postgres MCP server — all installed together.

So which do I use?

Here's the decision, as a radio group. Pick the sentence that matches your need; the right tool and a concrete example appear on the right.

Common pitfalls

Stuffing CLAUDE.md with everything. CLAUDE.md is always in context. Every line costs tokens, every turn. Keep it to the stable facts. If it changes per task, make it a skill.

Using a skill when you needed a hook. If Claude might skip a skill invocation in a bad turn, but you absolutely must run the check, that's a hook. Skills are best-effort; hooks are guaranteed.

Using a hook when you needed a skill. Reverse failure. If the action requires judgment — "read this PR and decide if the migration is safe" — a hook is the wrong shape. Hooks are dumb-on-purpose.

Building a plugin before you need one. If you're the only one using the setup, a folder of skills + a settings.json with hooks is enough. Plugins earn their weight when more than one person installs them.

Tiny mental model

To wrap: CLAUDE.md is what Claude knows. Hooks are what the harness enforces. Skills are what Claude can reach for. Plugins are how you distribute all of the above. Get those four verbs right and the rest follows.