Sub-Agent vs. Slash Command: Which Do I Write?

The short answer

Write a slash command when you want a reusable, parameterised prompt that you (or Claude) can fire on demand — “do this specific thing now”. Write a sub-agent when you want a focused assistant that Claude can delegate a class of work to, often automatically — “whenever a situation like X comes up, hand it off to this specialist”. Slash commands are verbs; sub-agents are roles.

Side by side

Decision guide

Walk down this list; stop at the first one that matches.

1. Do you want to type something short to kick off a known workflow? (/commit, /changelog, /review-pr 123) — that's a slash command. Especially if it takes arguments or needs to inlinegit status / a config file.
2. Do you want Claude to recognise a recurring kind of task and hand it to a specialist on its own? (“after writing code, get it reviewed”; “for any database migration, use the migration expert”) — that's a sub-agent. The description is the trigger.
3. Do you need the work isolated in its own context (so a long investigation doesn't flood the main conversation)? — sub-agent. Sub-agents run as separate sub-tasks and report back a summary.
4. Is it really just a saved prompt you reuse a lot? — slash command. Don't reach for a sub-agent when a template will do.

They compose

The two aren't mutually exclusive. A common pattern: a slash command that does the mechanical setup, then explicitly invokes a sub-agent for the judgement-heavy part — e.g. /review-pr checks out the branch and runs the tests, then hands the diff to a code-reviewer agent. Build the pieces with the Claude Code Agent & Slash-Command Builder and wire them together.

Once you've decided

• Sub-agent: see what is a Claude Code sub-agent for the full file format.
• Slash command: see the slash-command frontmatter reference for every key and placeholder.
• Either way, the builder gives you a validated, copy-ready file.