I caught myself typing the same 200-word prompt for the fourth time in a week. "Write a conventional commit message for the staged changes, keep it under 72 chars on the first line, reference the issue if there's a branch number..." Every. Single. Time. That's the moment you should stop and build a slash command. So let's set up Claude Code slash commands and skills, and never retype that again.
Both features do the same basic thing — package up instructions so you can reuse them — but they're built for different jobs. Slash commands are for things you trigger. Skills are for things Claude triggers when a task calls for them. Get that distinction right and the rest is easy.
Slash commands: your shortcuts
A slash command is a saved prompt you fire with /name. You make one by dropping a markdown file in .claude/commands/ in your project. The filename becomes the command.
Let me kill that commit-message prompt for good. Create .claude/commands/commit.md:
Write a conventional commit message for the currently staged changes.
Rules:
- First line under 72 characters, imperative mood ("Add", not "Added").
- Type prefix: feat, fix, refactor, docs, test, or chore.
- If the branch name contains an issue number, reference it in the body.
- Show me the message. Don't run git commit yourself.
Run `git diff --staged` first to see what changed.
Now in any session I type /commit and Claude does the whole thing. Four words instead of two hundred. The file is the command — whatever's in it gets sent as my prompt when I invoke it.
Passing arguments
Commands get more useful when they take input. Use $ARGUMENTS as a placeholder. Here's .claude/commands/explain.md:
Explain how $ARGUMENTS works in this codebase.
Find where it's defined, trace how it's used, and give me a short
plain-English summary. Use a subagent to do the searching so you
don't fill up our conversation with file dumps.
Then /explain the auth flow drops "the auth flow" into that spot. One command, infinite uses. I have a dozen of these now — /test, /review, /changelog — and they've quietly removed most of the boilerplate from my day.
Skills: instructions Claude reaches for on its own
Slash commands are great when you know what you want. But sometimes you want Claude to apply specialized knowledge automatically, mid-task, without you remembering to invoke anything. That's a skill.
A skill is a folder with a SKILL.md file. The top of that file describes when the skill applies. Claude keeps that description in mind, and when a task matches, it pulls in the full instructions on its own. You don't type a command. It just happens.
Say your team has a strict way of writing database migrations. Create .claude/skills/migrations/SKILL.md:
---
name: migrations
description: How to write database migrations in this project.
Use whenever creating, editing, or reviewing a migration file.
---
Migrations live in db/migrations, named with a UTC timestamp prefix.
Every migration must:
- Be reversible — include both up and down.
- Never drop a column in the same migration that stops writing to it.
Split it across two deploys.
- Wrap schema changes in a transaction.
Before writing one, read the three most recent migrations to match style.
Now when I ask Claude to "add a migration for the new archived_at column," it notices the task matches the skill's description, loads these rules, and follows them — without me saying the word "skill." That's the magic of it. The knowledge shows up exactly when it's relevant and stays out of the way otherwise.
Which one do I build?
Here's the simple rule I use.
Build a slash command when you decide to run it. Commit messages, generating a changelog, kicking off a specific review — these are deliberate. You invoke them.
Build a skill when Claude should decide. Coding conventions, domain rules, formatting standards — anything that should apply automatically whenever a matching task comes up. You don't want to remember to type /migrations every time you touch the database. You want the rules to just be there.
A decent heuristic: if the sentence starts with "whenever Claude does X, it should..." — that's a skill. If it starts with "sometimes I want to..." — that's a command.
The description is the load-bearing part
For skills especially, the description line is everything. It's how Claude decides whether the skill applies. Vague description, skill never fires. Be concrete about the trigger: "Use whenever creating, editing, or reviewing a migration file" tells Claude exactly when to wake it up. "Database stuff" does not.
Same energy as a good tool description, honestly. You're writing for an agent that has to decide, in the moment, whether this thing is relevant. Give it a clear yes/no.
Start with the one that annoys you most
Don't sit down and build twenty of these. You'll guess wrong about what you actually need. Instead, wait until you feel the friction — that fourth retype, that rule you keep re-explaining — and build that one. Right then. It takes two minutes and the payoff is immediate.
My whole collection grew that way, one annoyance at a time. The commit command came from retyping commit prompts. The migrations skill came from fixing the same migration mistake twice. Each one solved a real, specific irritation I could point to.
So here's your homework. Next time you catch yourself typing a prompt you've typed before, stop. Open .claude/commands/, make a file, paste the prompt in. You just bought back every future copy of those two minutes. Do that ten times and your Claude Code setup stops feeling generic and starts feeling like yours.