Claude Skills vs Slash Commands: When to Use Each in Your Agentic Workflows
Claude Skills auto-invoke based on context while slash commands require manual triggers. Learn the difference and when each approach produces better results.
Two Tools, Two Different Jobs
When you’re building agentic workflows with Claude Code, you quickly run into a choice that trips up a lot of people: should this be a Skill, or should it be a slash command?
On the surface they look similar. Both extend what Claude can do. Both live in your workspace. But they work in fundamentally different ways, and using the wrong one for a given task creates friction that compounds quickly — especially as workflows get more complex.
The short version: Claude Skills auto-invoke based on context. Slash commands require you to manually trigger them. That single distinction determines almost everything about when you should use each one.
This article breaks down the real difference, walks through the decision criteria, and gives you a clear framework for structuring agentic workflows that don’t constantly need babysitting.
What Claude Skills Actually Are
A Claude Skill is a packaged capability that Claude can recognize and invoke on its own, without you typing a specific command. You define what the skill does, when it applies, and what inputs it needs. Claude handles the rest — matching context to capability and running the skill when it’s appropriate.
Skills are typically structured around a skill.md file that describes the process steps, plus any supporting reference files or scripts. When Claude encounters a situation that matches a skill’s described purpose, it invokes it automatically.
This makes Skills well-suited for:
- Repeatable processes that should happen the same way every time
- Context-triggered actions where you want Claude to detect the right moment to act
- Chained workflows where one skill hands off to another without manual intervention
For a deeper look at how the architecture works, see why your skill.md file should only contain process steps — the separation between process logic and reference data matters a lot in practice.
Skills also benefit from being composable. You can chain multiple skills into end-to-end workflows, passing outputs from one as inputs to the next. That’s where Skills really separate from commands.
What Slash Commands Are
Slash commands are manual triggers. You type /command-name (sometimes with arguments), and Claude executes a defined behavior immediately. Nothing is inferred. Nothing is automatic. You called it, it runs.
Claude Code ships with a number of built-in slash commands:
/simplify— reduces over-engineered code or instructions to a cleaner version/batch— groups related tasks to run together efficiently/loop— runs a recurring task on a defined cycle within your session/btw— lets you ask a clarifying question mid-task without breaking flow/voice— switches to voice input mode
You can also define custom slash commands for your workspace. These are useful for tasks you want to trigger explicitly, on demand, in a specific order.
The /simplify and /batch commands are a good example of what slash commands are best at: corrective actions you decide to take in the moment, not something you want Claude inferring on its own. The /btw command is similar — it’s a deliberate interruption, not something you’d want auto-triggered.
The Core Difference: Intent vs. Context
Here’s the clearest way to think about the distinction:
| Skills | Slash Commands | |
|---|---|---|
| Trigger | Automatic, context-driven | Manual, explicit |
| Best for | Recurring processes, workflow steps | On-demand actions, corrections, session control |
| Invocation | Claude detects when to run | You decide when to run |
| Composability | High — designed to chain | Low — typically standalone |
| Overhead | Low at runtime | Low at runtime, but requires your attention |
| Control | Delegated to Claude | Stays with you |
Skills are about delegating a pattern. You’re saying: “Whenever this situation arises, handle it this way.”
Slash commands are about staying in control. You’re saying: “Right now, I want this specific thing to happen.”
Neither is better. They serve different moments in a workflow.
When to Use Skills
Use a Skill when you’re encoding a process that should run the same way every time, regardless of which session you’re in or whether you remember to invoke it.
Recurring business processes
If you’re doing the same 7-step process every time a new piece of content comes in — research, outline, draft, review, format, optimize, publish — that’s a Skill. You don’t want to manually invoke each step. You want Claude to run the process when content arrives. Building a full business workflow from a single skill is exactly this pattern.
Context-triggered actions
Skills shine when the trigger is a condition, not a command. “When a PR description is missing acceptance criteria, add them.” “When a new research document is added to the folder, generate a summary.” These aren’t things you want to remember to ask for manually.
Multi-step pipelines
If your workflow has more than two steps that need to execute in sequence, Skills are almost always the right choice. Chaining skills into an agentic OS lets you build systems where Claude coordinates an entire process end-to-end without you intervening between steps.
Team workflows
When multiple people need to run the same process consistently, Skills enforce that consistency. A slash command in someone’s head isn’t repeatable across a team. A defined Skill is.
When to Use Slash Commands
Slash commands belong in your workflow when you need direct, immediate, one-time control — especially for things that shouldn’t happen automatically.
Mid-task corrections
If Claude is working on something and you realize it’s getting too complex or wandering off track, /simplify is exactly right. You don’t want Claude auto-simplifying things — that would break intentional complexity. But you do want to be able to call it when you see the problem.
Session management
Commands like /loop and /voice are session-level controls. You’re configuring how Claude behaves right now, not defining a workflow that runs on its own. Slash commands are the right fit because the trigger is always “I want this now.”
One-off tasks
If something only needs to happen once, during this session, there’s no reason to build a Skill for it. Slash commands handle this cleanly. They’re lower overhead to invoke and don’t require any setup.
Asking questions without interrupting flow
The /btw command is a good example of a command that has no Skills equivalent. When you want to ask Claude a question mid-task without breaking the current context, that’s an explicit, deliberate act. Automating it would make no sense.
Effort and behavior tuning
Configuring effort levels for a specific task is another example. You’re making a judgment call about how much compute to apply to the current problem. That’s not something you’d want inferred — it’s something you set.
Where They Can Overlap (and How to Decide)
Some cases sit in the middle. Here’s how to think through the ambiguous ones.
“I run this process a lot, but not on every session.” That’s a Skill. Frequency doesn’t matter as much as consistency. If you want the same behavior every time you do it, define it as a Skill.
“I want to trigger this manually, but have it run multiple steps.” Start with a slash command that invokes a Skill. Claude Code supports this pattern — a command can be the entry point that kicks off a defined Skill workflow. You get explicit control over when it starts, but structured automation after that.
“I’m not sure if Claude will invoke the Skill at the right time.” This usually means your Skill’s trigger conditions aren’t well-defined. Revisit the process description in your skill.md. Common mistakes when building Skills often come down to vague invocation logic — Claude can’t know when to run a Skill if the conditions are ambiguous.
“This only happens in certain projects.” Skills can be scoped to specific workflows or contexts. You don’t need a single global set of Skills. If something is project-specific, define it at that level.
How These Fit Into Agentic Workflow Architecture
The real power of combining Skills and slash commands comes when you think about them as different layers in a workflow system.
At the automation layer, Skills do the heavy lifting. They handle the repeatable, predictable work that Claude should execute without prompting. This is where you invest time in designing good processes — clear trigger conditions, well-defined steps, explicit outputs. If you’re building toward a full agentic OS architecture, Skills are the building blocks.
At the control layer, slash commands let you stay in the loop without micromanaging every step. You can interrupt, redirect, batch, repeat, or simplify at any point without disrupting the underlying Skill architecture.
This layered approach is described well in the four-pattern framework for Claude Code Skills, which covers how context, memory, collaboration, and self-learning patterns each play a role in more complex systems.
It’s also worth noting that agentic workflows can include conditional logic and branching — Skills can be built to take different paths based on what they find, making them more adaptive than a simple slash command ever could be.
Building Skills That Actually Auto-Invoke Correctly
The most common frustration people hit with Skills is that Claude either invokes them at the wrong time or doesn’t invoke them when expected. This almost always comes down to how the trigger conditions are written.
A few things that help:
Be specific about conditions, not intent. “Use this skill to write blog posts” is too vague. “Use this skill when a user provides a blog topic, target keyword, and desired word count” gives Claude something concrete to match against.
Use code scripts over markdown instructions for complex steps. This is counterintuitive at first, but code scripts outperform markdown instructions for agent tasks because they remove ambiguity. When the steps are procedural, script them.
Keep skill.md focused on process, not context. Reference data, brand guidelines, and background information belong in separate reference files. Your skill.md should contain exactly what needs to happen and in what order — nothing else.
Test with real inputs. It’s easy to assume a Skill will invoke correctly until you actually test it against a variety of prompts. Skills 2.0 evaluation and A/B testing exists precisely because real-world invocation behavior often differs from what you expect during design.
Where Remy Fits in This Picture
If you’re using Claude Code Skills and slash commands to build structured workflows, Remy represents the next level of that same idea.
Remy compiles annotated markdown specs into full-stack applications — backend, database, auth, frontend, deployment. The spec is the source of truth. The code is derived from it. The same principle applies: you define intent at a high level, and the system handles execution.
In practice, this means the workflows you’re building in Claude Code — whether through Skills that auto-invoke or slash commands you trigger manually — can eventually point toward something more permanent. A spec-driven application that captures those same processes as part of a production system, not just a session workflow.
Skills are great for codifying repeatable processes. Specs take that one level further: they codify what the entire application is, in a format both you and an AI agent can reason about and modify over time.
If you’re building workflows that are starting to feel like they belong in an actual product, try Remy to see what spec-driven development looks like in practice.
Frequently Asked Questions
Can a slash command trigger a Skill?
Yes. You can set up a slash command that serves as an explicit entry point into a Skill workflow. This gives you manual control over when a process starts while still getting the benefit of Claude’s structured, multi-step execution once it’s running. It’s a useful pattern when you want to decide when a workflow fires, but don’t want to manage each step manually.
Do Skills persist across sessions?
Yes. Skills are defined at the workspace or project level, not the session level. They’re available every time you open Claude Code in that context. Slash commands built into Claude Code also persist, though custom session-specific behaviors (like /loop settings) reset when the session ends.
What’s the difference between a Skill and a plugin?
Skills are Claude Code’s native way to package and invoke reusable capabilities. Plugins are a broader extension category that can include third-party integrations, tools with external APIs, and more. The line can blur — the Skills vs Plugins comparison covers the architectural differences in detail, including when you’d build one versus the other.
How many Skills can I have before it gets unwieldy?
There’s no hard limit, but organizational clarity matters more than count. If Claude is getting confused about which Skill to invoke, it usually means Skills are overlapping in scope. Group related capabilities into a single Skill with branching logic rather than creating many narrow Skills with similar trigger conditions. The skill collaboration pattern addresses how to structure collections of Skills so they stay coherent.
Should I use Skills or slash commands for scheduled tasks?
Neither is a perfect fit for truly scheduled tasks (time-based, calendar-driven). Slash commands are session-dependent — they don’t run when you’re not there. Skills auto-invoke during a session but don’t fire on their own. For time-based automation, Claude Code Loop vs Scheduled Tasks covers the architectural difference and when each approach makes sense.
Can Skills learn from previous runs?
Yes, with the right setup. Skills can be built to write learnings back to a reference file after each run, which gets read on the next invocation. This creates a feedback loop over time. Building a skill that learns from every run explains how to implement this pattern without adding significant complexity to the core process.
Key Takeaways
- Skills auto-invoke based on context. Slash commands require explicit manual triggers. This is the core distinction.
- Use Skills for repeatable, structured processes you want Claude to handle consistently without being asked each time.
- Use slash commands for on-demand control — corrections, session configuration, one-off tasks, and anything that shouldn’t happen automatically.
- They work better together than separately. A slash command can kick off a Skill. A Skill can surface results you then act on with a command.
- Vague trigger conditions are the most common Skills failure. Be specific about when a Skill should fire, and use code scripts for complex procedural steps.
- Both fit into a larger agentic architecture where automation and control operate at different layers — Skills handle delegation, commands handle oversight.
Start with the question: “Do I want Claude to decide when to do this, or do I want to decide?” That one question will get you to the right tool most of the time. And as your workflows grow in complexity, the patterns for combining them will become clearer.
Try Remy at mindstudio.ai/remy if those workflows are starting to look like they belong in a production application.