Claude Code gives you three different ways to package a repeatable workflow, and it's easy to pick based on which one you learned about first rather than which one actually fits. All three can hold the same checklist — the difference isn't what they can contain, it's what invoking them changes: whether it loads automatically or has to be named, whether it runs in your context or a fresh one, and whether it can pick its own model. Get that mapping wrong and you end up with a slash command that should have been automatic, or a subagent that silently threw away context you needed.
A skill is the right container when you want the behavior to trigger without anyone remembering to ask for it. You write a description of when it applies, and the model decides to pull it in based on the current task — nobody has to type a command or know the skill's name. That makes skills the best fit for "whenever X happens, do Y": whenever there's a migration file, run the safety checklist; whenever a chart is requested, apply the palette rules. It runs inline in the current conversation, so it can see everything that's already happened and add to it directly.
The tradeoff is the same thing that makes it convenient: discovery isn't guaranteed. If the description is vague or the task doesn't obviously match, the skill won't fire, and there's no error — it just silently doesn't apply. A skill is only as reliable as its trigger description is specific.
A subagent is the right container when you want the work done in a context that isn't yours — either because it needs a lot of exploration that would bloat the parent conversation, or because you want it running with a different model or a restricted toolset. A code-search sweep across fifty files, a long research task, a review pass that shouldn't be able to edit files — these belong in a subagent because the parent conversation only needs the answer, not the scratch work that produced it.
The tradeoff is the isolation itself: a subagent starts cold, with no memory of the conversation that spawned it, so the prompt has to be self-contained, and its intermediate reasoning is invisible to the parent unless it's explicitly reported back. Using a subagent for a task that needs the parent's context — recent edits, an ongoing decision, a half-finished plan — just means re-deriving that context at a cost, for no benefit.
A slash command is the right container for a workflow that should never run implicitly — something destructive, expensive, or specific enough to a moment that auto-triggering would be wrong more often than right: cutting a release, running a paid multi-agent review, deploying. Naming it removes any ambiguity about whether it's about to happen, which is exactly the property you want when the answer to "did I mean to do this right now" needs to be yes on purpose.
The tradeoff is that it never fires on its own — if the person driving forgets the command exists, or forgets to run it, nothing prompts them. A slash command is a good container for judgment-gated actions and a bad one for anything you'd want to happen automatically every time a condition is met.
| Question | Answer points to |
|---|---|
| Should this happen without anyone asking, whenever the situation matches? | Skill |
| Does this need a lot of exploration/scratch work that shouldn't pollute the main conversation, or a different model/toolset? | Subagent |
| Is this destructive, expensive, or something that must only run on deliberate request? | Slash command |
| Does it need the full context of the current conversation to do its job? | Skill (in-context) — not a subagent |
These aren't mutually exclusive: a slash command can spawn a subagent to do the heavy lifting and return a summary; a skill can instruct the model to launch a subagent for the exploration-heavy part of its own procedure. The decision at each layer is still the same one — automatic vs. named, inline vs. isolated — just asked again one level down.
This is a packaging decision, not a workflow one — it doesn't replace having a correct procedure to package. The checklists in the Claude Code Power Pack and Claude Code Debug Pack are the procedures; each pack also ships one subagent for the exploration-heavy step in its domain, chosen for exactly the isolation reasons above. There's a fourth container worth knowing too — see hook vs. skill for when a rule needs to be guaranteed rather than just likely to fire, and git worktrees for parallel agents for isolating the filesystem itself once more than one of these is running at once.