Claude Code Subagents vs Skills: What's the Difference?

Subagents and skills are two of the most-asked-about Claude Code features, and the names invite confusion because both live under the same broad question: how do I get Claude Code to do more, reliably. They are not competing options. They solve different problems and are commonly used together.

A subagent is a separate Claude Code instance the main agent spawns to run a piece of work independently, with its own context and tools, then report back. A skill is a packaged, reusable set of instructions, usually a slash command your whole team can invoke, that tells an agent exactly how to do something specific.

This guide compares the two directly: what each one is for, where they overlap, and the pattern most teams land on once they have used both for a while.

Subagents vs. Skills: Side-by-Side

What Subagents and Skills Actually Are

A subagent is a worker. When the main Claude Code agent needs to do several independent things at once, such as searching three parts of a codebase, reviewing a diff for security and performance separately, or refactoring three unrelated modules, it spawns a subagent per task. Each subagent gets its own context and tool access, runs on its own, and reports its findings back to the parent when it finishes.

A skill is a recipe. It is a markdown file in.claude/commands/ that packages a prompt your team uses repeatedly, such as a release checklist, a specific code-review format, or a way you always want a migration written, into a slash command. Type the command and every team member gets the same instructions instead of writing their own prompt from scratch.

The short version: subagents are about how the work runs, in parallel, in isolation. Skills are about what the work should follow, a consistent, shared set of instructions.

• Subagent: a worker spawned to do a piece of work independently.
• Skill: a packaged, reusable prompt shared as a slash command.
• Subagents answer "how do we split this up."
• Skills answer "what should everyone do the same way."

When to Reach for a Subagent

Reach for a subagent when a task naturally splits into independent pieces that do not need to see each other's work. Fan-out search, spawning several Explore agents to check different parts of a codebase for the same question, is the clearest example, because each search runs faster and more focused on its own.

Subagents also fit parallel code review, where a security-focused pass, a performance-focused pass, and a style pass genuinely benefit from separate full attention instead of one agent trying to hold all three concerns at once, and multi-file refactors, where worktree isolation lets several subagents edit different modules at the same time without conflicting.

When to Reach for a Skill

Reach for a skill when the same task comes up again and again and you want everyone on the team to do it the same, good way. A release checklist, a standard PR-review format, or a house style for writing a migration are all skill candidates. Write the instructions once, save them as a slash command, and stop re-explaining the same context every time.

Skills are also the right layer for governance. A team lead can review and update a shared skill in one place, and everyone who runs that slash command picks up the improvement immediately, instead of each person's ad-hoc prompt drifting apart over time.

Using Subagents and Skills Together

The most capable setups use both. A skill can tell an agent to spawn a specific set of subagents as part of its instructions, for example a "full PR review" skill that always fans out a security subagent, a performance subagent, and a style subagent, then synthesizes their findings into one report. Anyone on the team gets that exact workflow by typing one slash command.

A subagent, in turn, can be told to follow a skill while it works, so a spawned worker inherits the same house standards a human-triggered run would use. Skills provide the shared instructions; subagents are the workers that can execute them in parallel. They compose rather than compete.

We build multi-agent Claude Code workflows for client engagements at Layer3 Labs, and the pattern that shows up on almost every team we work with is a small library of skills that encode the team's actual standards, paired with a handful of custom subagent types tuned to specific jobs (a fast, cheap type for search and lookup, a slower, more capable type reserved for judgment calls). Teams that skip the skill layer and only use ad-hoc subagent prompts tend to see the most inconsistency between runs, since nothing enforces the same instructions twice.

The Verdict

Subagents and skills are not alternatives. They answer two different questions. Use subagents when a task splits into independent pieces that benefit from running in parallel with full, undivided attention. Use skills when a task repeats and you want the whole team doing it the same, well-tested way.

Most teams that get real value from Claude Code end up using both: skills to standardize the instructions, subagents to run pieces of that work in parallel. Start with whichever problem you actually have. Inconsistency points to skills; slow sequential work points to subagents. Add the other once the first one is paying off.