Skills vs Slash Commands: One Works, One's a Prayer.
The most confusing distinction in Claude Code, finally explained. Three differences that actually matter.
This is the most confusing distinction in Claude Code. Both are "reusable prompts." Both save you from typing the same thing repeatedly. Both are shareable. Both sound like they do roughly the same job. The documentation makes them seem interchangeable, like choosing between Pepsi and Coke.
They are not interchangeable. Three differences matter:
- Who pulls the trigger: Slash commands run when YOU invoke them. Skills run when CLAUDE decides they're relevant.
- Who provides context: Slash commands take arguments —
/draft-linkedin-post [topic] [bullets]tells Claude exactly what to write about. Skills infer context from the conversation and codebase. - Token cost: Slash commands get inserted into context every time you invoke them. Skills only load their description until activated — the full content lazy-loads.
Control and clarity vs automation and efficiency. Pick your trade-off.
Slash commands: you're in control (finally)
Slash commands run when you type them. Period. Full stop. No ambiguity. No hoping. No praying to the AI gods.
You type /draft-linkedin-post, it runs. You type /commit, it commits. Revolutionary concept, I know. In an age of magical AI that's supposed to read your mind, there's something deeply satisfying about a tool that just does what you tell it when you tell it.
I have /draft-linkedin-post that takes a topic and bullets, then outputs a post in my voice. Same structure every time. I don't want Claude to get creative with the format — I want consistency. I want to type a command and get a predictable result. Like some kind of digital caveman using primitive trigger-response technology.
Other examples:
/commit— standard commit message format/review— code review with my preferred checklist/atomize-content— break an essay into platform-specific posts
The key: if you're giving the same instructions more than twice, make it a slash command. Your fingers will thank you. Your sanity will thank you. Your token budget might even thank you.
Skills: Claude decides (when it feels like it)
Skills are instructions that Claude is supposed to invoke automatically when relevant.
The theory — and I'm using "theory" here the same way physicists use it when they're 90% sure but can't prove it — is that you write a skill with a nice description, Claude reads it, and magically invokes it when the context matches.
The reality: skills don't always fire automatically.
Sometimes Claude picks them up. Sometimes it doesn't. Sometimes you have to explicitly say "use the X skill" anyway, which kind of defeats the entire purpose of having an "automatic" system. It's like having a self-driving car that occasionally requires you to grab the wheel and steer. Very reassuring.
The dirty secret nobody wants to admit
Go read r/ClaudeCode threads about skills. I'll wait. Actually, I'll save you the trip:
"It hardly picks up any skill without actually telling it to use it"
"Skills would be awesome if it actually used them properly"
"Skills are basically just reminders to the LLM"
That last one is painfully accurate. Skills are fancy prompts that Claude may or may not remember exist. They're like Post-It notes you stick on your monitor hoping your future self will notice them. Sometimes you do. Sometimes you walk past them for three weeks wondering why that yellow blob is in your peripheral vision.
Someone actually tested this
Scott Spence ran 200+ tests on skill activation. The results:
- Simple instruction hook: 20% activation (coin flip)
- Forced eval hook: 84% activation
The difference? Commitment mechanisms. Instead of passively hoping Claude notices skills exist, the forced eval hook makes Claude explicitly evaluate EACH skill with YES/NO reasoning before proceeding.
Once Claude writes "YES — need this skill," it's committed. It's harder to bypass something you just agreed to use.
The takeaway: skills can work reliably — but not out of the box. You need hooks to force the evaluation. Which kind of defeats the "automatic" promise.
So why do skills exist? (There are actual reasons)
Three legitimate use cases:
1. Lazy loading saves tokens.
Your CLAUDE.md is always in context. Always. Every conversation. Every token. Skills, on the other hand, are loaded on demand — at least in theory. If you have a 500-line CLAUDE.md because you kept adding "just one more instruction," consider breaking domain-specific stuff into skills.
Your wallet will appreciate this eventually.
2. Organization for the obsessive-compulsive among us.
Instead of one massive CLAUDE.md that reads like a legal document, you can have modular skills: one for frontend patterns, one for API conventions, one for content writing. It's cleaner to maintain. It makes you feel like you have your life together. Whether Claude actually uses them correctly is a separate question.
3. Sharing your neuroses with teammates.
You can package skills and share them with your team. "Here's how I want code reviews done" becomes a shareable artifact instead of a 47-message Slack thread that nobody will ever read.
When to use which (the practical guide for people with deadlines)
Use slash commands when:
- You want to control exactly when it runs
- The task has fixed steps
- Consistency matters more than flexibility
- You don't trust Claude to figure out when to apply it (wise)
Use skills when:
- Instructions only apply sometimes (not every conversation)
- You want to reduce CLAUDE.md bloat
- You're okay with Claude deciding relevance (optimistic)
- You want to share patterns across projects/teams
- You're mentally prepared to invoke them explicitly anyway
My approach (learned through pain)
I default to slash commands. I want control. I've been burned too many times by "intelligent" systems that aren't quite intelligent enough.
I use skills for domain-specific instructions that would bloat my CLAUDE.md unnecessarily. My post summarizer skill doesn't need to be in context when I'm debugging Python. My code review preferences don't need to load when I'm drafting blog posts.
When I create a skill, I mentally prepare to invoke it explicitly. If Claude picks it up automatically, great — I'll take that win. If not, I type "use the X skill" and move on with my life. No frustration. No existential crisis. Just pragmatic acceptance that the future isn't quite here yet.
This is post 2 of 4. Next up: agents — and when to stop trying to script everything like it's 2015.
I help technical founders develop, deploy, and market their SaaS using Claude Code. These workflow lessons cost me several weeks and more tokens than I'd like to admit.