Claude Code Skills vs Slash Commands: When to Use Each

Two Ways to Control Claude Code — and Why Most People Confuse Them

Most people who start using Claude Code treat slash commands and skills as interchangeable. They’re not. They operate at completely different layers, solve different problems, and the choice between them affects how much manual work you do every single session.

The short version: Claude Code Skills auto-invoke based on what you’re doing. Slash commands require you to type something first. That distinction sounds small. In practice, it changes everything about how you build and run agentic workflows.

This article breaks down exactly what each mechanism is, how each one works under the hood, and when you should reach for one over the other.

What Claude Code Skills Actually Are

If you haven’t spent time with the skills system yet, start with what Claude Code skills are and how they work — it covers the fundamentals well.

The short version: a skill is a structured file (typically skill.md) that tells Claude how to handle a specific type of task. When Claude detects that the current context matches the conditions described in that skill file, it runs the skill automatically. You don’t type anything. You don’t invoke it. It just fires.

Skills are designed around process. They define:

What triggers the skill (the detection condition)
What steps to follow once triggered
What output or action to produce

The detection mechanism is key. Claude reads the context of what you’re doing — what files are open, what you just wrote, what the task description says — and pattern-matches against available skills. If there’s a match, the skill runs.

This is what makes skills suited for recurring, predictable tasks that you want handled consistently without having to prompt for them each time.

For example: you’re adding a new API endpoint. You have a skill configured for that. Claude recognizes the pattern, invokes the skill, follows the process defined in the file, and produces output that matches your team’s standards — without you typing a single instruction.

One important architectural note: your skill.md file should contain process steps, not reference material. Packing skills with background context, style guides, or explanatory prose bloats the file and degrades performance. Keep skills lean and action-oriented.

What Slash Commands Actually Are

Slash commands are explicit, user-initiated instructions. You type /command, and Claude executes that command. Nothing runs until you ask for it.

The built-in slash commands cover a range of utility functions:

/compact — Compresses the current context window to reduce context rot
/simplify — Strips overengineered solutions back to something leaner
/batch — Runs multiple tasks in a single pass
/btw — Asks a clarifying question mid-task without losing your place
/voice — Switches to voice input mode

Each of these is documented in more detail separately. For example, how /simplify and /batch fix overengineering is worth reading if you haven’t used those two yet. And if you’re dealing with a bloated context window, using /compact to prevent context rot explains exactly when and how to apply it.

You can also create custom slash commands — essentially shorthand for long, frequently-used prompts. Instead of typing out a 200-word instruction every time you want Claude to do a specific thing, you define /mycommand and let that expand into the full instruction.

Custom slash commands are stored as files in .claude/commands/. Each file contains the instruction text. When you type the slash command, Claude reads the file and executes it.

This is where the line between commands and skills starts to blur — and where most people get confused.

The Core Difference: Triggered vs. Invoked

Here’s the clearest way to think about it:

	Skills	Slash Commands
Activation	Automatic (context-based)	Manual (user types command)
Best for	Recurring, patterned tasks	One-off or situational actions
Control	Claude decides when to run	You decide when to run
Setup	skill.md file with detection logic	Command file in .claude/commands/
Consistency	High — same process every time	Variable — depends on when you invoke

Skills assume you’ve thought ahead. You’ve identified a task pattern, defined the process, and now you want that process to run every time Claude encounters that pattern — without you having to think about it.

Slash commands assume you’re making a judgment call in the moment. You see something that needs addressing. You type a command. You get a result.

Neither is better in the abstract. The right choice depends entirely on the task.

When Skills Win

Use a skill when the task meets all three of these criteria:

It happens regularly. If you’re writing the same kind of code, doing the same kind of review, or generating the same kind of output more than a few times a week, a skill pays off.
The process is well-defined. Skills work because they give Claude a specific set of steps to follow. If you haven’t figured out what those steps are, you’re not ready to write a skill yet.
You want consistency without manual effort. The whole point of auto-invocation is that you stop having to think about it. The skill runs. The output is consistent. You move on.

Practical examples where skills are the right answer:

Code review on every PR. Define the criteria, write the skill, let it trigger every time Claude sees a diff.
Generating tests for new functions. Claude detects a new function is added and automatically runs the test-generation skill.
Enforcing a commit message format. Every time you commit, the skill fires and formats the message to spec.
Content repurposing. You paste a blog post; the skill automatically reformats it for LinkedIn, Twitter, and email. There’s a full walkthrough of how to automate social media content repurposing with skills if this is a use case you’re building for.

Skills also become more powerful when chained. One skill’s output becomes the next skill’s input, building end-to-end workflows that run autonomously. How to chain Claude Code skills into end-to-end workflows covers how this works in practice, including multi-skill pipelines where each step hands off to the next.

The more your work follows recognizable patterns, the more skills can carry the load.

When Slash Commands Win

Use a slash command when the task is situational, reactive, or one-off.

The classic case is context management. Your session has been running for a while. The context window is getting long. Things are starting to get slow or inconsistent. You type /compact and the window gets trimmed. That’s not something you’d want triggering automatically — it should happen when you decide the context needs pruning.

Similarly, /btw is designed for moments when you need to ask Claude a question mid-task without interrupting the flow. How /btw saves tokens by letting you ask questions mid-task explains the mechanics — it’s a good example of a command that’s useful precisely because it’s manual. You choose when to pause.

Other situations where slash commands are the right call:

Debugging a specific output. You got something unexpected. You want to run /simplify on just this section. You decide that, not Claude.
Batch processing a one-time list. You have 40 items to process today. /batch handles it. You wouldn’t want a skill firing every time you create a list.
Switching modes. You want to switch to voice input for a few minutes. /voice does it on demand.
Running occasional audits. You want Claude to review your whole codebase for a specific pattern once a month. That’s a slash command moment, not a skill.

Custom slash commands are particularly useful as “personal macros.” If you have a long prompt you use every few days — say, a full code review rubric or a detailed content brief template — wrapping it in a custom slash command means you type /review instead of pasting 300 words. That’s not automation. That’s ergonomics.

The Gray Zone: Custom Slash Commands That Act Like Skills

Here’s where it gets nuanced.

A custom slash command containing a detailed process description starts to look a lot like a skill. Both define steps. Both produce consistent output. The difference is trigger mechanism: you invoke the command, but the skill invokes itself.

Whether you should use one or the other in these cases comes down to a single question: Do you want this to run every time the context matches, or do you want to decide when it runs?

If a task needs human judgment to decide when it’s appropriate — run it as a slash command. If the pattern is predictable enough that you’d always want it running when conditions are met — turn it into a skill.

Some teams do both. They start with a custom slash command to test a process, iterate on the instruction, and once it’s working reliably, convert it into a skill with an auto-detection condition. This is a reasonable workflow. You’re not committing to the skill’s auto-invocation until you’ve validated the process manually.

For teams building more complex workflows, the four-pattern framework for Claude Code skills is worth understanding. It gives you a structured way to categorize skill types, which makes it easier to decide when a custom command should graduate into a skill.

Common Mistakes When Choosing Between Them

Turning everything into a skill

Auto-invocation has a cost. Every skill that runs adds processing overhead and token usage. If you’re triggering skills on every minor action, you’ll burn through context and slow down sessions.

Reserve skills for tasks that are genuinely worth automating. Not every task needs to run automatically just because you can make it do so. Common mistakes when using Claude Code skills covers this and two other patterns that regularly trip people up.

Relying on slash commands for things that should be skills

The opposite problem is equally common. Some teams end up with 20 custom slash commands that they invoke manually for tasks that follow identical patterns every single time. That’s a lot of cognitive overhead. If you’re always typing /generate-tests after writing a new function, that should be a skill.

The test: if you invoke the same command more than three or four times a week in the same context, it should probably be a skill.

Overloading skill files with context

Skills should describe process steps, not carry background knowledge. If your skill file contains your company’s style guide, architectural notes, and a philosophy section, it will degrade over time. Context rot in Claude Code skill files is a real problem — bloated files make Claude less reliable, not more.

Keep skill files focused on what to do, not why to do it or everything the agent might ever need to know.

Building Toward a Full Agentic Workflow

The most sophisticated Claude Code setups don’t treat skills and slash commands as separate tools. They use each where it belongs as part of a larger system.

Skills handle the predictable, high-frequency work automatically. Slash commands give you control points — places where you step in to redirect, adjust, or trigger something manually. Together, they form a workflow that runs most of the time without intervention, but stays steerable when you need it.

This is the foundation of what people mean by an agentic operating system: a set of skills, memory, and controls that lets Claude handle your work with minimal hand-holding. How skills chain into business workflows in a full agentic OS goes deeper into how these pieces fit together.

If you’re building toward that kind of setup, the progression usually looks like this:

Start by identifying the repetitive tasks in your workflow.
Write custom slash commands for them. Use them manually for a week or two.
Once the process is stable, convert the high-frequency ones into skills with detection conditions.
Keep slash commands for situational and one-off needs.
Chain skills where tasks naturally hand off to each other.

That progression keeps you from over-engineering too early, which is how most skill-based systems go wrong.

Where Remy Fits

Remy takes a different approach to the same underlying problem: reducing how much manual setup you need to get consistent, production-quality output.

With Claude Code, you’re writing skill files, defining detection conditions, and managing the interaction between skills and commands yourself. That’s powerful, but it requires ongoing maintenance — keeping skill files lean, updating processes when things change, monitoring for context rot.

Remy works from a spec: a structured markdown document that describes what your application does. The code is compiled from that spec, not written and maintained by hand. When something changes, you update the spec and recompile.

If you’re building full-stack applications and want the same “define once, run consistently” approach that skills offer — but at the application level rather than the task level — try Remy at mindstudio.ai/remy. The spec-driven model handles a lot of the orchestration problems that skill systems are designed to solve, but at a higher level of abstraction.

FAQ

What is the main difference between Claude Code skills and slash commands?

Skills auto-invoke when Claude detects a matching context. Slash commands require you to type them manually. Skills are for recurring, pattern-based tasks you want to run automatically. Slash commands are for situational actions where you want to decide when something runs.

Can I use slash commands and skills at the same time?

Yes, and most effective workflows do both. Skills handle the predictable, high-frequency work without manual input. Slash commands give you control over one-off actions, context management, and situations that require judgment. They’re not in competition — they complement each other.

When should I convert a custom slash command into a skill?

When you’re invoking the same command repeatedly in the same context. If you’re always typing /generate-tests after writing a new function, or always running /format-commit when committing code, those are strong candidates for skills. If the task needs you to decide when it runs — keep it as a command.

Do slash commands affect the context window?

Some do. Commands like /compact are specifically designed to manage context length. Others, like /btw, are designed to be lightweight — asking a quick question without consuming much of the context budget. If context management is a concern, pay attention to which commands you’re using and how often. More on this in how /compact prevents context rot.

How many skills is too many?

There’s no hard ceiling, but performance degrades as the number of active skills grows. Every skill file adds to what Claude needs to process. A focused set of 5–10 well-scoped skills typically outperforms a sprawling library of 30+ overlapping ones. Quality and specificity matter more than quantity.

Can skills and slash commands trigger other skills?

Skills can chain — one skill’s output can trigger another skill in sequence, building multi-step workflows. Slash commands can kick off processes that then run through a skill chain. How far you extend this depends on how complex your workflow needs to be. For teams building full pipelines, how to chain skills into end-to-end workflows covers the collaboration patterns in detail.

Key Takeaways

Skills auto-invoke. They run when Claude detects a pattern match. Use them for recurring, predictable tasks where consistency matters.
Slash commands are manual. You type them when you need them. Use them for situational, one-off, or judgment-based actions.
Custom slash commands sit in the middle. They’re great for testing processes before converting them into skills, and for tasks you want to invoke occasionally but not automatically.
Skill files should stay lean. Process steps only — no background context, no philosophy, no style guides. Bloated files degrade performance.
The best workflows use both. Skills for automation, slash commands for control. Together, they let Claude handle the routine while keeping you in charge of the exceptions.

If you’re building applications rather than just automating tasks, try Remy at mindstudio.ai/remy — it brings the same “define once, run consistently” philosophy to full-stack development through a spec-driven approach.