Skills, memory, hooks, and agents look like cousins until you've used the wrong one for the job. This chapter is the decision you make before you write anything.
By Chapter 6 you know what a skill is. Now the harder question: when isn't a skill the right answer? There's a small family of Claude primitives that all look similar from a distance. They have very different jobs.
The whole chapter, in one sentence: hooks fire by themselves, memory holds facts, agents do bounded jobs, and skills are the recipe Claude reaches for when you ask. Get that straight and most architectural decisions become obvious.
Here's the whole field on one page. Read this once, slowly. Most of the chapter is just nuance on top.
| Primitive | What it is | Trigger | Persistence |
|---|---|---|---|
| Skill | A markdown recipe Claude reads when triggered | User invokes (explicit or implicit) | Per-invocation |
| Memory | Persistent files at ~/.claude/projects/<cwd>/memory/ |
Always loaded into context | Across sessions |
| Hook | Shell command in settings.json, fires on events |
Automatic on configured events | Stateless per fire |
| Agent | A sub-task Claude dispatches | Claude decides during a task | One-shot |
Skills are recipes. Memory is facts.
A skill says "here's how to deploy a static site": find the build directory, rsync to the host, print the URL. Memory says "the user's deploy target is evil.lt and they prefer scp." One describes a procedure. The other holds the data the procedure works on.
The two are easy to mix up because they're often used together. The deploy skill reads the memory entry to know where to ship things. That doesn't make them the same primitive — it just means good skills lean on memory rather than re-asking the user.
Two heuristics that almost never lie:
Skills wait. Hooks fire.
A skill sits in ~/.claude/skills/ doing nothing until something triggers it — you type a slash command, or your phrasing matches its description. It's a recipe pinned to the fridge: useful, ready, but never moving on its own.
A hook lives in settings.json and runs by itself on configured events: PostToolUse, OnFileChange, SessionStart, and so on. The harness watches for the event and executes the hook for you. No invocation, no thinking about it, no prompt required.
The decision is almost mechanical:
Hooks don't live in the skills folder. They're configuration, not content. If you've ever written a hook, you know you're touching settings.json, not creating a folder.
Skills are persistent recipes. Agents are one-shot sub-tasks.
A skill is something you wrote down once and keep using. An agent is something Claude dispatches mid-task — a fresh context, a focused job, a result that comes back when it's done. The agent disappears when the work is finished.
The relationship is usually skills call agents, not the other way around. The book-builder skill spawns one Opus agent per chapter. The skill is the recipe; the agents do the actual work the recipe defined.
If you catch yourself debating "should this be a skill or an agent?" — almost always the answer is: the skill is the architecture, and inside it you might dispatch agents to do the heavy lifting. The two compose; they don't compete.
The fifth option is the one nobody mentions: don't build anything at all.
For a one-off task, skip the abstraction. If you want a function explained line by line, just say that. If you want a SQL query for tonight's report, write the prompt. Skills, memory, hooks, and agents are all overhead — they pay off only when you'll do the same thing again.
A loose rule that holds up:
This is also true in reverse. If you're staring at a skill you wrote three months ago and haven't touched since, it might just be a long prompt that never paid off — fine to delete.
Picking a primitive isn't permanent. Things drift; that's healthy. Here are the moves that come up most.
You wrote down "I always deploy via scp to evil.lt" as a memory entry. Six months later you've got steps, fallbacks, post-deploy checks. The fact has grown into a procedure. Codify it as a skill and keep the bare facts in memory.
You've got a format-on-save skill, and you find yourself invoking it after every edit. The invocation is no longer the point. Move the trigger to a hook — PostToolUse with a prettier --write command — and stop thinking about it.
You wrote a skill that's really just restating a fact: "the user prefers pnpm." There's no procedure in there. Move it to memory and delete the skill.
You've typed the same kind of request five times this week. Stop typing it. Write the skill once.
The same scenario set, three answers, three different primitives. Read the scenario, then read why.
PostToolUse entry in settings.json with prettier --write. A skill would require you to invoke it; the whole point is not to.Five yes/no questions. Most decisions only need two or three. Tell it the shape of what you want and it'll show you the primitive plus a starter snippet.
Click any arrow between the four boxes to read a short case study on that migration. The arrows are the moves that actually come up in practice.
Six scenarios. Guess the right primitive first, then flip the card to check. Score yourself.
Two side-by-side examples — both very much not-a-skill. The first is a memory file (a fact). The second is a hook fragment in settings.json (an automation). Recognising the shape of each is half the battle of not reaching for a skill when you don't want one.