Claude Code skills vs subagents vs slash commands: when to reach for which

Claude Code gives you three distinct mechanisms for extending what it can do: slash commands, subagents, and skills frameworks. All three show up in discussions about "the right way to set up Claude Code," and all three are sometimes confused for each other. They solve different problems, put you in control at different moments, and the friction of using the wrong one for the wrong job shows up fast.

This piece is a neutral guide: what each mechanism actually is, when each one is the right tool, and where developers get the tradeoffs wrong.

Slash commands: you trigger, Claude executes

Slash commands are the simplest mechanism. You create a markdown file in .claude/commands/<name>.md — project-scoped — or in ~/.claude/commands/<name>.md for personal commands that travel with you across projects. The filename becomes the command: update-changelog.md gives you /update-changelog. The file body is the prompt Claude receives when you invoke it. You can pass inline arguments via $ARGUMENTS, embed live shell command output using shell injection, and use optional YAML frontmatter to lock in a model or pre-approve specific tools.

What they're good for: repeatable workflow steps you want to invoke on demand without re-explaining the context. Running your test suite and summarizing failures. Generating a changelog entry from recent commits. Seeding a database with test data to a specific schema. Anything where you know exactly what you want Claude to do and you want a single command to trigger it.

The key property is manual control: you decide when to invoke the command, and the command executes in the current conversation context. Slash commands are personal workflow automation — they don't compose into a methodology and they don't spawn parallel workers. They're a text-expansion shortcut with Claude as the executor.

Where developers go wrong: trying to use a single slash command to orchestrate a multi-step workflow. A /ship-feature command that tries to plan, implement, review, and open a PR in one shot usually produces worse results than scoping each step separately. Slash commands work best when they're bounded and precise.

Subagents: Claude decides to delegate

Subagents are a different level of abstraction. When Claude Code uses the Task tool, it spawns a fresh Claude Code instance with its own context window, tools, and objective. That instance runs to completion and returns a result. Subagents are not something you invoke — they're something Claude invokes, when it decides a bounded piece of work is better delegated than handled inline.

Claude Code supports up to 20 concurrent subagents (as of July 2026) with configurable nesting depth (default 3). An agent can spawn subagents, and those subagents can spawn their own — up to the depth limit. The primary use case is parallelism: Claude Code spinning up multiple subagents to search different parts of a codebase simultaneously, or to run tests for multiple modules in parallel while the main loop does something else.

What they're good for: bounded, parallelizable subtasks where the input and output contract is clear. Finding all usages of a deprecated API across a codebase. Writing tests for three independent modules at the same time. Running security analysis on multiple files in parallel. The subagent model is powerful when the task fan-out is real — when there's genuine work to do in parallel, not just a multi-step workflow you want to be hands-off about.

Where developers go wrong: expecting subagents to improve results on tasks that aren't actually parallelizable. Spawning subagents for sequential steps doesn't make them faster — it adds coordination overhead. And because each subagent starts with a clean context window, they don't share the conversation history, decisions, or context your main session has built up. Tasks that require accumulated context — like a multi-file refactor where early decisions affect later ones — generally work better in-session than delegated to subagents.

The more important distinction: subagents are not a user-facing mechanism. You don't invoke them. Claude decides to use them. If you want parallel work, you architect the prompt so Claude has a reason to fan out. If you want manual control over parallel execution, you're in slash command or harness territory.

Skills frameworks: opinionated methodology packages

Skills frameworks like Superpowers and GSD are a third thing entirely. They're curated collections of instructions, rules, and workflow components that you install into Claude Code — typically via CLAUDE.md, project settings, or a setup command — and which shape how Claude behaves across an entire project, not just on individual invocations.

Superpowers (obra/Jesse Vincent) is the most opinionated example: it enforces a TDD discipline — test first, always — to the point where it deletes code written before tests exist. It defines a methodology, not just a set of commands. GSD (TÂCHES/gsd-build) takes a lighter approach: spec-driven task management with defined workflow steps, but without Superpowers' rigidity. gstack focuses on scaffolding and governance — project conventions, naming rules, architectural guardrails.

What they're good for: teams or solo developers who want a consistent methodology applied automatically, without re-explaining it on every session. If you've decided on TDD, Superpowers enforces it so you don't have to. If you want spec-first planning, GSD structures that. The value is consistency across sessions — your CLAUDE.md carries the framework, and Claude starts every task already knowing your process constraints.

Where developers go wrong: installing multiple frameworks that conflict with each other, or adopting one that imposes a workflow that doesn't match how you actually work. Superpowers' TDD enforcement is a feature for some developers and a blocker for others. Framework choice is a methodology choice — if the framework's opinions aren't your opinions, you'll spend time fighting it.

It comes down to who's in control, and when

The clearest way to separate the three mechanisms is to ask who's making the decision and when.

mechanism	who invokes it	scope	best for
slash commands	you, manually	single bounded task	repeatable steps you know and trust
subagents	Claude, programmatically	parallel bounded subtasks	genuine fan-out work with clear I/O contracts
skills frameworks	always-on (via CLAUDE.md / project config)	whole project, every session	consistent methodology enforcement across sessions

They compose, but they're not interchangeable. A developer running Superpowers can also write project-specific slash commands for their own workflow steps — the framework sets the methodology, the commands handle the one-offs. A developer using subagents for search can also have slash commands for repeatable analysis tasks. The mechanisms work at different layers.

What the mechanism question misses

All three mechanisms answer the question "how do I get Claude Code to do the right thing more consistently?" None of them answer the question "how do I stay in control of what my agents are doing across a multi-stage project?"

Slash commands, subagents, and skills frameworks all operate within a session. The cross-session problems — how decisions made in the architecture stage constrain the implementation stage, how a reviewer agent catches what the implementer missed, how you gate release on meaningful criteria rather than just "does it build" — are outside the scope of what any of these mechanisms handles.

That's a different layer: not which mechanism Claude uses within a task, but how tasks are structured, staged, and governed across an entire software development lifecycle. defract addresses that layer — a structured lifecycle (story → design → architecture → implementation → review → release) that runs on top of Claude Code rather than within a single session. It's a different scope than a skills framework or a set of slash commands, and it doesn't replace them — it sits above them.