Claude Skill vs Prompt vs Memory vs Subagent: What to Use When
Four primitives, one decision. Cut through the confusion between Claude prompts, CLAUDE.md memory, skills, and subagents. Pick the right tool every time.
A prompt is a note you leave for a model and throw away. A skill is infrastructure you build once and run forever.
This is part of a cluster on Claude Code skills. If you have never built one, start with the ground-level guide to creating Claude Code skills: SKILL.md, references, the loading map, and when a skill is worth building at all.
Which primitive do you need? Four options: prompt, memory, skill, subagent. The answer is not a matter of preference. Each fits a different contract, and picking the wrong one means either building infrastructure you did not need or retyping the same instructions until they drift.
What each primitive actually is
Four tools. Four completely different contracts. All four can produce the same output in a single session. The difference is what happens next week, when the work comes back.
A prompt is a one-session instruction. You write it, the model reads it, the session ends and it is gone. Fastest tool, most disposable. No versioning, no structure required.
Memory (your CLAUDE.md at the project or user level) is persistent, always-on context. It does not trigger. It loads every session automatically. Standing rules and always-true facts live here: your stack, your conventions, your tone. None of it should need saying twice.
A skill is a versioned, reusable method. It has a SKILL.md with a name and a description. The model reads those fields every session and knows when the skill applies. When it triggers, it loads its references. The method stays consistent because it lives in a file, not your memory.
A subagent is an isolated worker. It forks the context into a clean slate. Not for better answers: for isolation and parallelism. Long jobs that would degrade the main context, or tasks you want to run in parallel, belong there.
The four primitives at a glance
- 0
- sessions it survives
- ∞
- sessions it loads in
- 1
- trigger: a description
- 1
- forked context per call
Prompt: one-shot, then gone
Memory: always on, no trigger
Skill: versioned, reusable method
Subagent: isolated worker
When a prompt is the right call
For a task you will never repeat, in the same form, across sessions: a prompt is the correct tool. No setup, no overhead, done.
The question that decides it: “Will I need this exact behavior again next week?” If no, write the prompt. The cost of building a skill for a one-off is real (a day of distillation, versioning, and testing). The cost of writing a prompt is not. There is no prize for infrastructure you do not need.
Where prompts break down is repetition. If you are typing the same multi-paragraph instruction three sessions in a row, you are doing the skill’s job by hand and drifting slightly each time you retype it. Three repetitions is the threshold. Past that, the variation in how you phrase it produces meaningfully different outputs. That is not a prompt problem. That is a missing skill.
When CLAUDE.md memory is the right call
Always-true context belongs in memory, not in a prompt you repeat every session. If it is true today and will still be true in six months, it is memory.
Your stack (Astro, TypeScript, Tailwind), your conventions (English only, dark-only, no arbitrary CSS values), your voice (no AI-tells, first-person): none of these need to be triggered. They need to be on. Every session. Without you asking. CLAUDE.md does that.
Memory is not a method. It does not teach the model how to run a security review or how to apply a consistent editorial style. It tells the model what is always true about the project. If you are writing “when the user asks for X, do Y, then Z” inside CLAUDE.md, that logic belongs in a skill, not memory.
When to build a skill
A skill fits when three conditions hold: the work repeats, it requires a specific method, and it must produce consistent results across sessions.
One condition alone is not enough. Work that repeats but is trivial (run tests, stage a commit) is handled by an alias or a short prompt. Work that requires a specific method but only runs once belongs in a prompt. Work that must be consistent but is entirely about always-true facts belongs in memory.
All three together: that is the signal to build.
The heuristic I use in practice: have I explained the same workflow to the model three or more times? If yes, the model has forgotten it three times. That is not a prompt problem. That is a missing skill.
My skill library is proof of the rule in action. Skills like alex-hormozi (offer design), neil-patel (SEO audits), dhh (editorial rewrites), and the full lifeos-* suite (second-brain operations: capture, ingest, review, journal, query) exist for the same reason: the work recurred, needed a specific method, and kept varying session to session without a file to hold it.
Should this be a skill?
- Required:I have run this workflow more than twice across separate sessions.
- Required:The output varies when I do not specify the method explicitly.
- Required:The task requires more than one decision: frameworks, references, checklists.
- Required:I need the same behavior regardless of how I phrase the request.
- Required:I want to version and improve the method over time.
When you need a subagent
A subagent is not for harder work. It is for work that needs isolation.
Two cases where isolation is the right answer: the task is large enough to degrade the main context (a full codebase scan, a long research pass across many files), or you want to run multiple tasks in parallel without interference. The subagent forks the context, does its job, and returns a result. Your main thread stays clean.
The skill-vs-subagent distinction is the most frequently confused one. A skill is a method. A subagent is a worker. They solve different things. They also compose: a subagent can invoke a skill. If you have a recurring, method-driven audit that you want to run in parallel on three codebases, the right answer is a skill inside a subagent, not one or the other.
For the mechanics of that boundary, the guide on Claude skills vs MCP subagents goes deeper.
The matrix: scoring each primitive for recurring, method-driven work
These rules are clear in isolation. In practice the work shows up ambiguous. This matrix scores each primitive across the criteria that matter when the work repeats and the method has to hold.
Which primitive fits recurring, method-driven work?
| Criterion (weight) | Prompt | Memory | Skill | Subagent |
|---|---|---|---|---|
| Persists across sessions (3) | 1 | 5 | 5 | 1 |
| Encodes a specific, repeatable method (4) | 1 | 2 | 5 | 2 |
| Triggers only when relevant (2) | 3 | 1 | 5 | 3 |
| Stays consistent session to session (3) | 1 | 3 | 5 | 2 |
| Zero overhead for a one-off task (1) | 5 | 3 | 1 | 1 |
| Weighted score | 21 | 37 | 61 | 24 |
Scale 1-5 (5 = best). Highlighted column: winner by weighted score.
The score is not a verdict that skills are generically better than the others. It is a verdict that skills are the right tool for this specific class of work. Change the task class and the winner changes. A genuine one-off (a question you will never ask again) does not need a skill. A prompt is faster and correct.
The mistake everyone makes first: role prompting instead of a skill
Most people reach for a long system prompt to describe an expert persona, session after session, and believe this is equivalent to a skill.
It is not. The prompt decays. You drift each time you retype it. It is not versioned, so two sessions that “both used the Hormozi prompt” may have used subtly different instructions. The model’s outputs vary accordingly.
Zheng et al. (arXiv:2311.10054, Findings of EMNLP 2024) tested 162 personas across four model families. A bare persona label in a system prompt does not improve factual accuracy over no persona at all. Voice changes. Knowledge does not.
A skill is different because it carries the method: distilled references, a loading map, frameworks, decision criteria. The persona article in this cluster, why persona skills beat role prompting, covers the mechanics. The short version: identity without method is a costume. A skill supplies the method.
Closing
Four primitives. One rule: match the tool to the contract.
One-off? Prompt. Always-true context? Memory. Recurring, method-driven, must be consistent? Skill. Isolated or parallel worker? Subagent.
The signal that you picked the wrong one is simple. If you are retyping the same instruction more than twice, you are doing the skill’s job by hand. The guide to building Claude Code skills shows you how to stop.
FAQ
What is the difference between a Claude skill and a prompt?
A prompt is a one-session instruction that disappears when the session ends. A skill is a versioned module with a SKILL.md, a description that triggers it, and reference files that carry the method: the same behavior every session.
The practical difference shows up at the third repetition. If you have typed the same multi-paragraph instruction three times across separate sessions, you have been doing the skill's job by hand.
What should go in CLAUDE.md versus a skill?
CLAUDE.md holds always-true context: your stack, conventions, language, design rules. They load every session without a trigger.
A skill holds a method: a repeatable workflow with its own references, frameworks, and decision logic. If you find yourself writing step-by-step instructions for recurring work inside CLAUDE.md, move that logic into a skill.
When do I need a subagent instead of a skill?
When you need isolation or parallelism, not a better method. A subagent forks the context so the main thread stays clean. Useful for long jobs that would degrade the conversation, or tasks you want to run simultaneously.
Skills and subagents are not alternatives. They compose: a subagent can invoke a skill. If the work is recurring and method-driven and large, the answer is a skill inside a subagent.
Is a long system prompt with a persona equivalent to a skill?
No. A system prompt decays: you retype it each session and drift. Zheng et al. (arXiv:2311.10054, Findings of EMNLP 2024) found that a bare persona label in a system prompt does not improve factual accuracy over no persona at all. Voice changes; knowledge does not.
A skill carries the knowledge: distilled references, a loading map, frameworks. The persona is an activation coordinate, not the method itself.
How do I know when a workflow is worth turning into a skill?
Three signals: it recurs across sessions, it requires a specific method (not just a tone), and the output varies when you do not specify the method explicitly.
The threshold I use: if I have explained the same workflow to the model three times, the model has forgotten it three times. That is a missing skill, not a prompt problem.
Can I use a skill for a one-off task?
You can, but you should not. A skill has setup cost: distillation, versioning, testing. For a task you will never repeat, a prompt is the correct tool. Build the skill when the work recurs.
Does memory replace skills for persistent behavior?
No. Memory (CLAUDE.md) holds facts that are always true. A skill holds a method that triggers on demand. They serve different purposes.
If you want the model to always follow a certain convention, put it in memory. If you want it to execute a specific workflow when asked, put it in a skill. Putting a workflow into CLAUDE.md creates procedural logic in a context file. It cannot be versioned cleanly, and it will conflict with itself as it grows.