Claude Skills vs. Slash Commands vs. Subagents

Updated August 2026.

TL;DR: Slash commands are shorthand for a prompt you type often — you invoke them by name. Subagents are parallel workers with their own context window — you (or Claude) spawn them for a bounded task and get a result back. Skills are packaged expertise that Claude decides to load on its own, based on what you’re asking for, without you naming anything. Most people reach for a custom agent when a slash command would do, and reach for a slash command when what they actually needed was a skill Claude could trigger by itself.

[Operator’s read] I run 30+ production agents across two businesses, and this exact confusion — command, subagent, or skill — is the first design question on almost every one of them. Get it wrong and you either build ten commands nobody remembers the names of, or one skill so broad it never triggers reliably. The fix isn’t a rule of thumb, it’s asking what actually varies between runs.

Table of contents

Open Table of contents

• The three primitives solve different problems
• Slash commands: shorthand for a prompt you type often
• Subagents: parallel workers with their own context window
• Skills: packaged expertise Claude loads on its own
• The decision framework
• The mistake I see most
• The operator’s bottom line
• FAQ
  • What’s the difference between a Claude skill and a slash command?
  • When should I use a subagent instead of a skill?
  • Is it safe to let a skill auto-invoke actions like publishing or spending money?
  • Do I need to build all three eventually?

The three primitives solve different problems

All three let you package instructions once and reuse them. That’s where the similarity ends, and it’s also exactly why people mix them up — from the outside, “typing something short and getting a useful result” looks the same regardless of which one is doing the work underneath.

The real difference is who decides to invoke it, and what context it runs in:

• A slash command is invoked by you, by name. You type /deploy or /review, Claude expands it into a fuller instruction, and it runs in your current conversation.
• A subagent is invoked by you or Claude, for a task with a clear boundary. It gets its own context window, does the work, and reports back a result — it doesn’t see your whole conversation, and you don’t see its intermediate steps unless you ask.
• A skill is invoked by Claude, automatically, when your request matches what the skill’s description says it covers. You never type its name. If you don’t ask for something the skill handles, it never loads.

That third property — no explicit invocation — is the one people underuse. It’s also the one with the most leverage once you have more than a handful of packaged workflows, because you stop having to remember what you named things.

Slash commands: shorthand for a prompt you type often

Build a slash command when the trigger is “I keep typing basically the same instruction.” A command that always resolves to the same underlying prompt, expanded from a short name you chose, in the conversation you’re already having. No separate context, no autonomous invocation — you decide when it runs, every time.

Good fits: a fixed release checklist, a code-review pass with your house rules baked in, a “summarize this PR” shortcut. The command doesn’t need judgment about whether to run — you’re the one making that call by typing it.

The failure mode is building a command for something that actually needs the model to decide whether it applies. If half your usage is “wait, does this situation count?” — that’s a skill question, not a command question, because a command has no way to trigger itself.

Subagents: parallel workers with their own context window

Build a subagent when the task is bounded, delegable, and would otherwise pollute your main conversation with steps you don’t need to see. A subagent runs its own context — its own tool calls, its own back-and-forth — and hands back a result. This is the same principle I wrote about in context engineering: every extra tool call and intermediate step is context your main thread doesn’t need to carry, and a subagent is how you keep that noise out.

Good fits: “research this and report back,” “run these five independent checks in parallel,” “go fix this one file in isolation.” The task has a start, an end, and a deliverable — the exact shape the eval harness I use to ship agents treats as a single scoreable unit.

The failure mode is spawning a subagent for something that needed to stay in your main context because the next step depends on details the subagent’s summary dropped. If you keep having to re-ask the subagent “wait, what exactly did you find,” the boundary was drawn wrong — either fold it back into the main thread, or make the subagent’s report structured enough that nothing gets lost in translation.

Skills: packaged expertise Claude loads on its own

Build a skill when the trigger condition is something Claude should recognize from what you’re asking, not something you should have to remember to name. A skill is a description plus a bundle of instructions and scripts; Claude reads the description, decides if your request matches, and loads the full instructions only if it does. You never type /skill-name.

The clearest example I can point to is the one running the pipeline behind this blog. Alejandrorioja.com publishes in 13 languages, and the whole generate → translate → render → review flow lives in a single skill: a SKILL.md file describing when to use it (“generate a new post,” “translate into all locales,” “draft a promo”), plus the scripts that do the actual work. I don’t run four separate commands and remember their order. I say what I want in plain language, and the skill’s description is specific enough that Claude picks it up and runs the right steps — the same way the Facebook ads skill triggers on “check my ads” without me typing a command name.

That design choice — a skill deciding for itself when it applies — is also why the safety default matters more here than with commands or subagents. A slash command only runs when you type it; a skill runs when the model thinks it should. My content skill writes drafts by default and requires an explicit, separate approval step before anything publishes or pushes — the same human-in-the-loop pattern I use anywhere a skill can trigger itself into an action with real consequences.

Good fits: anything with a recognizable trigger phrase and a repeatable procedure behind it — “generate a report,” “grade this submission,” “draft a summary for Slack.” The failure mode is a skill description so broad it fires when you didn’t want it to, or so narrow it never fires when you did. Write the description the way you’d explain the trigger to a new hire, not the way you’d name a function.

The decision framework

Ask this	If yes →	Why
Do I always want to type a name to trigger this?	Slash command	You’re the trigger, not the model
Is the task bounded, delegable, and better kept out of my main context?	Subagent	Own context window, returns a result
Should Claude recognize the need without me naming anything?	Skill	Description-matched, auto-invoked
Does it touch money, publishing, or anything hard to undo?	Any of the three, plus an explicit approval gate	Auto-invocation is not the same as auto-execution

Most real workflows are a stack of these, not a single pick. My content pipeline is a skill (auto-triggered on “write a post”) that internally calls subagents (one per locale, running in parallel) and exposes a slash command (/publish) for the one step — going live — that should never happen without me explicitly saying so.

The mistake I see most

Building a full custom agent — its own scheduling, its own state, its own deploy — for something that was really a slash command wearing a costume. If the task is “run this exact procedure when I say so,” you don’t need autonomy, memory, or a trigger condition. You need a name and a prompt. Save the subagent-and-skill machinery for tasks where the boundary (subagent) or the trigger (skill) is actually doing work, not just adding infrastructure to something that was already simple.

The operator’s bottom line

Ask who decides to invoke it before you ask how to build it. You deciding, by name, every time → slash command. A bounded task you want out of your main context → subagent. Claude recognizing the need on its own → skill, with an approval gate on anything that can’t be undone. Get that one question right and the rest — what goes in the file, how much instruction to bundle — mostly falls out on its own.

FAQ

What’s the difference between a Claude skill and a slash command?

A slash command is invoked explicitly, by name, every time you want it to run. A skill is invoked automatically — Claude matches your request against the skill’s description and loads it without you naming anything. Use a command when you’re always the one deciding to trigger it; use a skill when the trigger condition is something the model should recognize on its own.

When should I use a subagent instead of a skill?

When the task is bounded and delegable and you want it to run in its own context window, separate from your main conversation — not because of how it gets triggered, but because of where the work happens. Skills and subagents aren’t mutually exclusive: a skill can spawn subagents internally, the way a translation skill might fan a post out to one subagent per locale.

Is it safe to let a skill auto-invoke actions like publishing or spending money?

Only with an explicit approval gate on the consequential step. Auto-invocation of the skill itself is fine — it just means Claude recognized what you’re asking for. The risk is auto-execution of anything hard to undo. Keep drafting, reading, and reporting inside the auto-triggered skill; require a separate, explicit confirmation for publish, pay, or delete.

Do I need to build all three eventually?

Only if your workflows actually have all three shapes. A solo operator with a handful of repeatable tasks might live entirely on slash commands for a long time. The need for skills and subagents shows up once you have enough distinct trigger conditions that you can’t remember command names anymore, or enough bounded sub-tasks that keeping them in your main context starts hurting quality.

---

Related: The Claude skill that runs my Facebook ads · Context engineering: what goes in the context window · Human-in-the-loop AI agents: when to build an approval gate · The agent stack I use to run 30+ production agents

Need help deciding what to automate and how? Get in touch — I design production agent systems for operator teams.