Commands, Skills and Subagents in Claude Code: What They Are and When to Use Each One
The three extension mechanisms of Claude Code explained in depth: how they are alike, how they differ and which use case fits each one best.
Until recently I did not quite understand the difference between using commands, skills and subagents in Claude Code. The three concepts are similar enough to get mixed up — after all, they all consist of giving Claude instructions — but each one solves a different problem. In this article I develop in detail what each thing is, how they differ and when it is best to use each one.
The starting point: all three are instructions in Markdown
Before looking at the differences, it is worth understanding what they have in common. A command, a skill and a subagent are defined, in essence, the same way: a Markdown file with a series of instructions that Claude must follow to perform a task. There is no need to program anything — you write in natural language what you want to happen, save it in the corresponding folder of the project (or of your user) and it becomes available.
The difference is not in the format, but in who decides when it runs and what context it works with. That is the key to everything.
Commands: controlled, explicit execution
A command is a Markdown file invoked by typing /command-name in the conversation. Its defining characteristic is that only you can launch it: Claude cannot decide on its own to execute a command even if, after reading your prompt, it considers it would be useful.
This, which at first glance looks like a limitation, is actually its strong point. There are tasks you want to happen exactly when you say so and never on the model's initiative:
- Deploying to an environment.
- Generating a report with a very specific format.
- Running a migration or a sensitive script.
- Launching a code review right before a commit.
Use them to launch controlled executions in specific cases. If the task has consequences or must follow a precise ritual, you want the determinism of a command: same trigger, same behavior, no surprises.
Skills: the same thing, but with initiative of its own
A skill is structurally almost identical to a command: a Markdown file with instructions. The big difference — and its great power — is that Claude can invoke it by itself if, after reading your prompt, it considers the skill useful for the task.
For example: if you have a skill documenting how tests are written in your project (framework, naming conventions, folder structure), you do not need to remember to invoke it every time. You ask Claude to "add tests for this service" and it detects on its own that the skill applies, loads it and follows your conventions.
There is one detail here that makes the difference between a skill that works and one that does not:
A good description answers "when should this be used?" with concrete triggers: it mentions the keywords, the task types and the contexts where it applies. Think of it as the "SEO" of your skill toward the model.
Command or skill: the quick rule
- Do you want full control over when it runs? → Command.
- Do you want the knowledge to be available whenever it is relevant, without having to remember it? → Skill.
Subagents: assistants who work for you (and save you tokens)
Subagents are something else. Without getting into a very technical definition: it is literally like having assistants during the development process who make your work easier and, on top of that, save you tokens.
A subagent is a separate instance of Claude, with its own definition (also in Markdown: its role, its allowed tools, its instructions) and — this is the important part — its own context, independent from your main conversation.
The example that made me understand it
Imagine you want that, every time a change is made to the project or a new development is completed, a security and quality analysis of the code is performed. You have two options:
- Asking Claude in your main conversation. It works, but that analysis drags along all the accumulated context of the conversation: every file read, every failed attempt, every explanation. All of that is tokens being processed over and over again.
- Delegating it to a reviewer subagent. The subagent does not need all the context of your main conversation — it only needs the diff and its review instructions. It does its job in its own clean context and returns only the result: the list of problems found.
That is precisely where the savings are. Your main conversation receives a summary of a few lines instead of being polluted with the whole review process. And the subagent works more focused because it does not carry irrelevant noise.
Other natural uses of subagents
- Code explorer: searches the project and returns only the conclusion, not the file dumps.
- Security reviewer: analyzes every change against a specific checklist.
- Documenter: keeps documentation up to date after each feature.
- Parallel tasks: several subagents working on independent fronts while you supervise.
Summary table
| Who invokes it? | Own context? | Typical use case | |
|---|---|---|---|
| Command | Only you (/command) | No — runs in your conversation | Controlled, specific executions |
| Skill | You or Claude (if it deems it useful) | No — runs in your conversation | Knowledge and conventions always available |
| Subagent | Claude (delegates the task) | Yes — independent context | Delegable tasks that would pollute your context |
Conclusion
The three mechanisms are Markdown files with instructions, but they answer different questions:
- Commands: "I want to launch this myself, when I say so".
- Skills: "I want Claude to know this and use it when appropriate".
- Subagents: "I want to delegate this to an assistant with its own context, and save tokens along the way".
Once you understand that division, moving from using them interchangeably to combining them is what truly multiplies what you can do with Claude Code. And if you want to go deeper, Anthropic's official courses on skills and subagents are the best next step.