Skills, Subagents, Commands, MCP: When to Use Which in Claude Code

The four-way confusion is real

One of the most upvoted Claude Code threads on Hacker News lately is not a feature request or a bug report. It is a complaint about the menu. There are now several overlapping ways to accomplish the same thing, a slash command, a skill, a subagent, an MCP server, and no clear guidance on when to reach for which. People are shipping real work with the tool and still guessing which primitive a given job belongs to.

I run Claude Code every day across a monorepo, a live freight automation, and the routines that maintain this site. I have reached for the wrong primitive enough times to have paid for the answer. This is the decision I actually use, with the mechanics that make the choice obvious once you see them.

The trap is that all four look similar from the outside. Two of them are invoked the same way, by typing a slash and a name. Two of them both do work. Two of them both extend Claude. So people sort them by vague size or vibe, a skill for small things, a subagent for big things, and that mental model is wrong. Sort them by mechanism instead and the overlap disappears.

The two axes that untangle everything

Forget size. Every one of these four is pinned down by two questions.

Who pulls the trigger, you or the model? A slash command only fires when you type it. A skill can fire on its own: Claude reads its one-line description, and when your request matches, it loads itself. That is the entire difference between the two things that both start with a slash.

Where does the work run, in your context, in a sealed one, or outside Claude entirely? Commands and skills run inline, in the same conversation, and what they produce stays in front of you. A subagent runs in a separate context window with its own tools and memory, and returns only a summary, so the exploration never touches your main thread. MCP runs outside Claude Code altogether: it is a protocol that lets the model call into another system.

Hold those two axes and the four primitives stop competing. They are answers to different questions.

Slash commands: a prompt you trigger

A custom slash command is the simplest of the four. It is a saved prompt, or a session directive, that you invoke by hand. You type the command and the saved instructions drop into the current session. It runs in your main context, right now, because you asked for it.

Reach for a command when you want to be the one deciding when it happens. A pre-flight checklist you run before every release. A review pass you want on demand, not automatically. A repeated instruction you would otherwise paste for the hundredth time. The defining trait is not what it contains, it is that the timing is yours.

What a command is not: it is not something Claude will reach for on its own, and it does not run in isolation. If you find yourself wishing Claude would just know to run it, you do not want a command. You want a skill.

Skills: a prompt Claude triggers itself

A skill is the same idea as a command, reusable instructions, with one difference that changes everything: Claude can invoke it without being told. Every skill carries a short description in its frontmatter, and that description sits in context cheaply. When your request matches it, the full skill loads inline and Claude keeps reasoning with those instructions in hand.

This is the primitive people underuse, because the payoff is invisible until it fires. A skill's description is a standing offer: when a question looks like this, here is how I handle it. You do not type anything. Claude recognises the shape of the task and pulls the playbook in. A command makes you remember to invoke the right procedure; a skill makes Claude remember for you.

Two mechanical facts are worth knowing before you lean on skills. First, descriptions are always loaded but full content only loads on use, so a dozen well-written skills cost very little until one is actually needed. Second, once a skill loads, its content stays in context for the rest of the session, so bloated skill files quietly tax every subsequent turn. Keep them tight; split reference material into supporting files the skill can pull only when required.

Use a skill when the trigger is a kind of task rather than a moment you choose: conventions your code should always follow, a deployment procedure, a domain rulebook. Use a command when you want the timing in your own hands. Same raw material, opposite trigger.

Subagents: a second Claude in a sealed room

Here is where the small-thing-versus-big-thing instinct really misleads people. A subagent is not a bigger skill. It is a structurally different thing: a separate Claude instance, spawned in its own context window, with its own tools and no access to your conversation. It does its work out of sight and returns only the result.

The point of a subagent is not capability, it is isolation. When I need to scan a large codebase, sift a pile of logs, or research a question that will generate pages of dead ends before the one useful paragraph, I do not want that mess in my main thread. A subagent absorbs all of it and hands back the conclusion. My context stays clean; the exploration is gone. The isolation is the feature.

It buys two more things. Parallelism: several subagents can run at once and report back independently, which is how you cover a lot of ground quickly. And control: each one can run on a cheaper model or a restricted tool set, so background grunt work does not cost frontier-model money or hold broad permissions.

The cost is real and worth naming: no back-and-forth. A subagent finishes and returns; you cannot steer it mid-task, and its separate context spends its own tokens. So a subagent earns its place when the work is self-contained, go find this, go analyse that, come back with the answer, not when you need a conversation. One nuance blurs the line: a skill can be told to run in a forked context, which effectively turns it into a subagent. Useful, but decide by the axis, not the syntax: do you want isolation, or not.

MCP: a bridge to the outside world

The first three are all prompt orchestration, different ways of arranging instructions and context inside Claude Code. MCP is a different category entirely. The Model Context Protocol connects Claude to systems it otherwise cannot touch: a Postgres database, the GitHub API, Sentry, Stripe, your Slack or Notion or Gmail. It exposes tools the model can call, data it can read, and prompts it can use.

So the MCP question is never is this reusable or should this be isolated. It is simpler: does the job require reaching an external system? File a real issue, query the production database, post to a channel, pull a live dashboard, that is MCP, because no amount of clever prompting lets Claude reach those on its own. It needs a connection, and MCP is the connection.

The distinction that trips people up is skill versus MCP, and it is clean once stated: a skill is knowledge, MCP is capability. A skill can hold your conventions for writing a good issue. Only an MCP server can actually file one. Instructions versus reach.

One production cost to respect: every connected MCP server's tool definitions consume context, so wiring up ten servers you rarely use is a slow tax on every session. Claude Code defers the full tool list until it is needed, which helps it scale, but the discipline still holds: connect what you use, prune what you do not.

The decision tree I actually use

Four questions, in order. The first yes is your answer.

One. Does the job need to reach an external system, a database, an API, a third-party service? If yes, it is an MCP server. Nothing else can cross that boundary.

Two. Is it reusable instructions or reference material, and do you want Claude to reach for it automatically? If yes, it is a skill.

Three. Is it reusable instructions you would rather trigger yourself, on your own timing? If yes, it is a slash command.

Four. Is it self-contained work whose exploration you want kept out of your main context, or run in parallel? If yes, it is a subagent.

Miss on this and the symptoms are specific. Build a subagent for something that needed a conversation, and you will fight its one-shot nature. Write a skill for something external, and it will describe an action it can never perform. Use a command where you wanted automation, and you will keep forgetting to run it. The wrong primitive does not fail loudly. It just quietly makes the work harder than it should be.

How they stack in real work

The primitives are not rivals; the good setups combine them. A concrete shape from my own work: a task kicks off from a command I trigger. Claude, reasoning through it, pulls in a skill that carries the conventions for how this kind of work should be done. It fans out subagents to research the unknowns in isolation, each returning a tight summary instead of a flood of exploration. And it reaches through MCP to read the live data and, once I approve, to act on the outside world.

That is the real mental model. Not which one is best, they are not on the same axis. It is who triggers it, where it runs, and whether it needs to reach outside. Answer those three and the menu that frustrated an entire Hacker News thread turns back into four tools that each do exactly one job.