Slash Commands vs. Skills

The key distinction between user-triggered slash commands and Claude-triggered skills, and when to build each.

Claude Code·Lesson 3 of 6·6 min

Slash commands and skills both package reusable capability, and both get confused with each other constantly on this exam. The distinguishing question is always: who decides when this runs?

Slash commands

A slash command is a reusable prompt template that the user invokes explicitly by typing /name. You write the template once — maybe it's /review-pr that expands into a detailed prompt asking Claude to check a diff against your team's style guide — and from then on, any time you (or a teammate) wants that exact workflow, you type the command. The user is the trigger. Claude never decides on its own to run a slash command; it waits to be invoked.

Slash commands are appropriate for workflows you perform repeatedly and want fast, predictable, on-demand access to — things where you always know in advance when you want them.

Skills

A skill is a packaged, discoverable capability with its own instructions, and possibly its own resources or scripts, that Claude invokes autonomously when it judges the current task matches the skill's purpose. You don't type anything to trigger a skill — Claude reads the task at hand, considers the skills available to it, and decides for itself whether one applies. The decision-maker is Claude, not the user.

Skills are appropriate when you can't predict in advance exactly when the capability is needed, or when you want Claude to reach for specialized behavior without the user having to remember a specific command name. A skill for "how to write database migrations in this repo's style" is more useful as a skill than a slash command, because Claude should reach for it any time a migration task comes up — including tasks the user described in plain language without knowing a migration-specific command exists.

Exam trap Scenario questions often describe a capability and ask whether a slash command or a skill is the better fit, without using the words "slash command" or "skill" directly — you have to infer it from who needs to make the trigger decision. A description like "Claude should notice on its own when a task involves X and handle it appropriately" points to a skill. A description like "the team wants a fast, consistent way to kick off their release checklist by typing a short command" points to a slash command. Answering based on surface features (e.g., "it involves multiple steps, so it must be a skill") instead of the trigger-ownership question is the trap — either construct can be simple or complex; the deciding factor is who initiates.

They can coexist

These aren't mutually exclusive tools competing for the same job — a mature Claude Code setup often has both. A team might have a skill that lets Claude autonomously recognize "this looks like a security-sensitive change" and apply extra scrutiny, while also having an explicit /security-review slash command for when someone wants to force that same scrutiny on demand, on a diff Claude might not have flagged on its own.

Scenario: An engineer wants Claude to automatically follow their company's API-versioning conventions any time it edits a public API file, without having to remind Claude every session. They also want a way to explicitly ask Claude to generate a full changelog entry when they're ready to ship. Which construct fits which need? The API-versioning behavior should be a skill — it needs to activate based on Claude noticing the file context, not based on the user remembering to ask. The changelog generation should be a slash command — the user knows exactly when they want it (at ship time) and wants a predictable, explicitly-triggered action, not something Claude guesses at.

Naming and discoverability

Because a user has to remember a slash command's name to invoke it, naming matters — an obscure or inconsistent name means the command effectively doesn't exist for anyone who forgot it. Skills don't have this problem in the same way, since Claude is the one scanning available skills against the task at hand, but that shifts the burden elsewhere: a skill's description needs to be written clearly enough that Claude can correctly judge relevance. A vaguely described skill either gets invoked when it shouldn't be, or ignored when it should apply. When you're authoring either construct, keep in mind who has to correctly recognize when to use it — the user reading a command list, or Claude reading a skill description — and write for that audience.

Try it

Create a slash command in .claude/commands/ for a workflow you do often, such as summarizing recent git history into a changelog draft, and invoke it with / plus the file name. Then write a minimal skill (a directory with instructions describing when it applies) for a narrower, context-triggered task, and test whether Claude picks it up on its own during a relevant task without you naming it explicitly.