Claude Code

Claude Code skills vs subagents: when to use which

Skills, subagents, slash commands and hooks all extend Claude Code. Here's the actual decision tree for which one fits which job.

In short

Use a skill when you want Claude to gain a new capability it can choose when to invoke. Use a subagent when you want to delegate a big, self-contained chunk of work that should run in its own context. Skills shape behaviour; subagents do work.

Claude Code’s extensibility surface, skills, subagents, slash commands, hooks, looks intimidating at first because the names overlap with each other and with industry terms that mean different things elsewhere. Here’s the actual decision tree, with Australian small-business examples.

The four primitives

PrimitiveWhat it isWho decides when it runs
Slash commandA typed shortcut that expands to a promptYou
HookA shell command on an eventThe harness (Claude Code itself)
SkillA capability with instructions Claude can invokeThe model
SubagentA separate Claude instance with its own contextYou or the model (via Agent tool)

When to use a skill

Skills are best when:

  • You have a repeatable workflow Claude should know about (e.g. “when writing a blog post in this repo, always include AuthorByline and KeyTakeaways components”)
  • The workflow needs conditional invocation, Claude decides when the skill applies
  • You want lightweight extension without paying for a separate Claude instance

Example we use: a skincare-sku-image skill that knows how to look up a product image URL from our internal Shopify catalogue and inject it correctly. When Jenn writes a skincare blog post, Claude offers to invoke it. When she writes anything else, it stays quiet.

A skill is essentially a Markdown file in .claude/skills/<name>/SKILL.md plus optional helper files. The SKILL.md describes the capability + when to use it; Claude reads it and decides.

When to use a subagent

Subagents are best when:

  • The work is big enough to merit its own context (research projects, audits, multi-file refactors)
  • You want to parallelise, kick off 3 audits in parallel and aggregate the results
  • The work has a clear deliverable the parent agent should consume (a report, a list, a recommendation)
  • You want to protect the parent context from a long tail of intermediate searches

Example we use: when we run our Lead Gen Empire link audit, the parent agent dispatches a subagent per vertical (20 of them). Each subagent crawls its assigned vertical’s pages, returns a broken-link list. Parent aggregates. Each subagent had ~50k tokens of intermediate output; the parent only sees the 20 final reports.

To dispatch a subagent, Claude uses the Agent tool. The agent type can be a general-purpose one or a specialist (e.g. an Explore agent that’s tuned for searching the codebase).

When you want a slash command instead

If you’re typing the same prompt three times this week, that’s a slash command. Slash commands have no model intelligence about when to fire, you decide. They’re great for “draft a quote in our standard format” or “summarise yesterday’s git activity.”

When you want a hook instead

If the requirement is “this should always happen on event X” with no model judgment involved, you want a hook. Formatters, lint gates, audit logs.

A real decision tree

Ask in order:

  1. Does it need to happen automatically on a system event? → Hook
  2. Do I always know when to invoke it (and can shortcut typing)? → Slash command
  3. Should Claude choose when to invoke it? → Skill
  4. Is the work big enough to deserve its own context? → Subagent

Common anti-patterns

  • Building a skill for one-off work. If you’ll only run it once, just write the prompt longhand. Skills are infrastructure.
  • Subagenting tiny tasks. A subagent has setup cost (new system prompt tokens, orchestration overhead). For a 30-second job, a skill or inline prompt is faster.
  • Skills that just repeat slash commands. If the model never decides “no, don’t invoke this skill right now,” it’s not a skill, it’s a procedure. Make it a slash command instead.
  • Hooks that do work better suited to the model. A hook that “decides” anything beyond pattern matching is misplaced. Move the decision to a skill.

Australian small business sizing

For most Australian SMB operators using Claude Code:

  • Day one: zero skills, zero subagents. Just claude and natural prompts.
  • Week two: one or two slash commands for your repeat workflows.
  • Month one: one or two hooks (formatter + an audit log is plenty).
  • Month three: your first skill, typically when you’ve noticed Claude needs the same scaffolding for a particular kind of task.
  • Month six+: subagents start to make sense, usually for bigger audit/research workflows.

Don’t engineer your Claude Code config ahead of your actual needs. Start sparse, accumulate as friction reveals itself.

Common questions

Can a skill spawn a subagent?
Yes. A skill can reference an Agent invocation in its instructions and Claude will dispatch accordingly. Common pattern: skill detects a research-shaped task, hands it to a subagent, waits for the report.
Do subagents share my prompt cache?
No. Each subagent is a fresh Claude instance with its own context window. That's part of the value, you don't pollute the parent context, but it does mean some token cost for the new system prompt.
How many subagents can I run at once?
Practically, 3-5 in parallel is the comfortable ceiling. More than that and the orchestration cost (your prompt time managing them) starts to eat the parallelism benefit.

Want this built for your business?

Book a free 30-minute AI audit. We'll map your business and show you exactly which systems we'd build first. No pitch deck, no scoping fee.

Book my free AI audit