Prompt, skill, or subagent?

Once you have a prompt worth keeping, the next question is where to put it. Claude Code offers four homes for an instruction, and the choice is usually made on vibes.

It is not a question about difficulty. It is two questions about lifetime and context.

#The four homes

A prompt

Typed once, in the moment. No file, no ceremony.

A skill

A markdown file holding a workflow or reference material. You invoke it, or Claude loads it when it becomes relevant. It runs in your conversation.

A subagent

A separate agent with its own context window and its own tool access. It does the work elsewhere and hands back a summary.

Project memory

The CLAUDE.md / AGENTS.md file. Always loaded, for every task, whether or not it is relevant.

#The first question: will I want it again?

If you will not, type it. Most good prompts are single-use and should stay that way. Turning every clever prompt into a file is how people end up with thirty skills and no idea which one fires.

If you will, it needs a file. Which file is the second question.

#The second question: where should the work happen?

This is the one people get wrong, and it is the one that matters.

In the conversation, as a skill. You want to see the steps. You will interrupt, redirect, and correct as it goes. The intermediate state is the point: you are going to look at it. A deploy checklist, a review pass, a project's way of writing a migration.

Out of the conversation, as a subagent. The work is going to read forty files and produce three sentences of conclusion. You want the conclusion, not the forty files, because those forty files would take up room you need for the actual task. That isolation is the whole feature.

So a subagent is not "for hard things". It is for noisy things. A search across a large codebase is trivially easy and belongs in a subagent. A subtle three-line fix is hard and belongs in front of you.

#Project memory is not a filing cabinet

CLAUDE.md loads on every single task, so everything in it costs you on every single task. It earns its place only if it is true for nearly all of them.

Things that belong: the commands to build and test, the conventions that are not visible from a single file, the traps someone has already fallen into.

Things that do not: anything you can read off the code, and anything that matters to one workflow. That last one is a skill, and moving it there makes both files better.

#Three worked examples

"Review my diff for security problems." Skill. You want to watch what it flags and argue with some of it, and you will run it constantly.

"Find every place we still call the old auth helper." Subagent. The answer is a list. The search that produces it is thirty tool calls you never need to see again.

"Always run the formatter before committing in this repo." Project memory. It is true for every task, it is one line, and it is invisible from the code.

#The failure mode of each

Worth knowing before you commit to one:

1. Too many skills and none of them fire, because nothing signals which is relevant. Fewer, with sharper descriptions, beats more.
2. Too many subagents and you lose the thread. Delegated work comes back as a summary, and a summary is exactly where a wrong assumption hides. Anything you will need to argue with should stay in front of you.
3. A bloated CLAUDE.md quietly taxes every task and buries the three lines that actually matter.

If you are unsure, leave it as a prompt for a week. The ones you keep retyping are the ones that have earned a file, and by then you will know exactly which of the two kinds it is.