Slash commands, skills, and sub-agents are three Claude Code primitives that overlap conceptually. Users routinely confuse them or use one when another would fit better. This article gives you a clear taxonomy: what each one is, where it lives in the workspace, how they invoke each other, and which to reach for when.
The 30-second taxonomy
| Primitive | Lives in | Invoked how | Mental model |
|---|---|---|---|
| Slash command | .claude/commands/*.md | User types /name | Keyboard shortcut for "do this thing" |
| Skill | .claude/skills/[name]/SKILL.md | Auto-loaded by description match, or by slash command | Procedure Claude follows when a kind of work appears |
| Sub-agent | .claude/agents/[name].md | Spawned by Claude via the Task tool | A separate Claude doing one bounded job in its own context |
The three are complementary, not competitive. A typical workflow uses all three: a slash command kicks off a skill, the skill runs in the main context but spawns sub-agents to parallelise the heavy work.
Slash commands
A slash command is the simplest of the three. It's a markdown file in .claude/commands/ whose contents are sent to Claude as if you'd typed them — but invoked with one keystroke chord (/commandname) instead of a full prompt.
.claude/commands/standup.md
---
description: Generate a standup update from today's git activity
---
Look at today's commits across all branches I've been on.
Summarise what I did in three bullet points: what I shipped,
what's in progress, what I'm blocked on. Use UK English.
Type /standup in Claude Code and that prompt is sent. The command name is the filename (without .md).
Frontmatter fields:
description— short text shown when listing commands; helps you remember what it doesname— override the default command name (otherwise derived from filename)
Use slash commands for: recurring prompts you don't want to retype, opinionated wrappers around common tasks, fast-access entry points for skills you use often.
Don't use slash commands for: complex multi-step work with branching logic — that belongs in a skill. Slash commands are essentially text expansion.
Skills
A skill is a procedure Claude follows when work matching its description appears. Skills are stored as a folder under .claude/skills/, with a SKILL.md file inside that defines the behaviour. The folder structure lets a skill carry templates, scripts, and examples alongside its instructions.
.claude/skills/writing-proposals/
├── SKILL.md
├── references/
│ └── proposal-structure.md
├── templates/
│ └── default-proposal.md
└── examples/
└── 2026-acme-proposal.md
SKILL.md frontmatter:
---
name: writing-proposals
description: Generate client proposals for AI productivity training. Use when asked to "write a proposal", "draft a proposal for [client]", or "prepare a proposal for [organisation]".
allowed-tools: Read, Write, Edit, Glob
---
# Writing Proposals
When invoked, follow these steps...
Frontmatter fields worth knowing:
- name — skill identifier (defaults to folder name)
- description — when Claude should auto-invoke this skill. Critical: this is what Claude reads to decide whether your request matches the skill. Vague descriptions miss invocations; over-broad descriptions invoke when they shouldn't.
- allowed-tools — pre-approve specific tools while this skill runs (saves prompts when you trust the skill)
- disable-model-invocation — set true if the skill should only fire when the user explicitly invokes it (not auto-loaded by description)
- context: fork — run the skill in an isolated sub-agent context (combines with
agent:field) - model, effort — override the default model or reasoning level for this skill
- paths — glob patterns; if the user mentions a file matching a path, the skill auto-activates
Loading model: skill descriptions are always in Claude's context (so it can decide which skill matches). The full SKILL.md content loads on-demand when the skill is invoked. This means you can have hundreds of skills without inflating context — only descriptions are always-loaded.
Use skills for: structured procedures with multiple steps; work that benefits from templates or examples; anything where you want Claude to behave consistently every time, not depending on prompt phrasing.
Don't use skills for: one-off prompts (use a slash command); broad behavioural rules (use .claude/rules/); workspace identity or conventions (use CLAUDE.md).
Sub-agents
A sub-agent is a separate Claude instance spawned by the main session to do one bounded task in its own context window. Sub-agents do not share conversation history with the parent; they receive only the task brief and any files they need to read. The parent gets back a final message (and any files the sub-agent wrote to disk).
Sub-agents are defined in .claude/agents/[name].md:
.claude/agents/researcher.md
---
name: researcher
description: Research a topic using web search and library tools, return a structured summary
tools: WebFetch, WebSearch, Read, Write
model: sonnet
---
You are a research agent. When given a topic:
1. Search authoritative sources
2. Verify claims across at least 2 sources
3. Write findings to /tmp/research-[topic].md as bullet points
4. Return only the file path and 1-line summary
Frontmatter fields:
- name — agent identifier
- description — when this agent type is appropriate (Claude reads this to decide which agent to spawn)
- tools — restrict the agent's tool access (smaller surface = safer + cheaper)
- model — model to use (sub-agents can use a different model than the parent)
Built-in agent types: Explore (read-only search), Plan (architectural planning), general-purpose (broad task agent). Custom agents in .claude/agents/ are discovered automatically.
Use sub-agents for: heavy reading or research that would balloon the main context; parallelisable work (research five topics at once); tasks where a focused, dedicated context produces better output than the cluttered parent context.
Don't use sub-agents for: quick questions that fit in the main conversation; tasks that need ongoing back-and-forth (sub-agents are one-shot); operations where you want every step visible in the main session.
For deep coverage of when and how to use sub-agents, see Sub-Agents and Parallel Execution Patterns.
How they invoke each other
The relationships go in roughly one direction:
You → slash command → invokes a skill → which spawns sub-agents for parallel work → which write to disk → orchestrator reads and returns to you
- Slash commands can invoke skills (just include the skill's trigger phrase in the command's prompt text)
- Skills can spawn sub-agents (the skill's instructions tell Claude to use the Task tool)
- Sub-agents can also invoke skills inside their own context (each agent has its own skill registry)
- Sub-agents cannot spawn more sub-agents in some implementations — check if you need deep nesting
Which one to reach for when
"I keep typing the same prompt"
Slash command. Save the prompt as .claude/commands/[name].md. Type /name from now on.
"I want Claude to do X consistently every time, not depending on how I phrase the request"
Skill. Write the procedure in .claude/skills/[name]/SKILL.md with a clear description that matches the kinds of requests you make.
"This task is going to use a lot of context — reading lots of files, doing lots of research"
Sub-agent. Spawn a separate context to do the heavy work; parent stays lean.
"I want to do five similar things at the same time"
Multiple sub-agents in parallel. Spawn them all at once via the Task tool.
"I want to enforce that Claude always does X before Y"
Hook, not a skill or command. Hooks are deterministic; skills and commands are instructions Claude follows when relevant. See Hooks Event Reference.
"I want Claude to know about my workspace"
CLAUDE.md or rules files. Skills and commands assume the workspace context is already there. Identity and conventions belong in CLAUDE.md; granular behavioural rules belong in .claude/rules/.
Common mistakes
- Cramming a skill into a slash command. Slash commands are text expansion. If the procedure has branching, sub-steps, or templates, it's a skill.
- Defining a sub-agent for work that fits in the main context. Sub-agents have overhead — context setup, separate model call, return handling. For small tasks, the parent doing it directly is faster and cheaper.
- Vague skill descriptions. If your description is "for content tasks", Claude will invoke it for every content question — over-broad. Be specific: "Use when asked to draft a LinkedIn post or convert long-form writing into a LinkedIn post." The description is the matching surface.
- Using a skill for one-off prompts. If you're going to use it three times, slash command. If you're going to use it twenty times across phrasings, skill. If once, just write the prompt.
- Forgetting that sub-agents don't share context. Sub-agents don't see the conversation; they only see the task brief and files. If a sub-agent needs context that's only in the conversation, the parent has to brief it explicitly.
Putting them together — a worked example
You run a small consulting firm and Claude Code helps you write proposals. Here's how the three primitives compose:
- CLAUDE.md — establishes that you're a consultant, your tone, your standard rates, common client types
- .claude/rules/communication.md — UK English, no emojis, professional register
- .claude/skills/writing-proposals/SKILL.md — the procedure: ask for client name, scope, budget; pull from research library; structure the proposal in five sections; save to a specific folder
- .claude/commands/proposal.md — a slash command that just contains "Write a proposal" so you can fire the skill with three keystrokes
- .claude/agents/researcher.md — when the proposal skill needs background on a client industry, it spawns this researcher to gather the material in parallel rather than doing it inline
Type /proposal. The slash command's text triggers the proposal skill. The skill collects the brief from you, then spawns the researcher sub-agent to pull industry context while you continue providing scope details. The sub-agent writes findings to disk; the skill reads what it needs; the proposal gets drafted.
None of these primitives could do that work alone. Used together, they replicate a workflow that would otherwise require a half-day every time.
