Custom slash commands and skills

Once your project memory is set, the next way to set AI up is to package the jobs you do often, so you are not explaining them from scratch every time. This takes two shapes, a command and a skill, and the difference comes down to who decides when it runs.

A command is a saved shortcut you call yourself by a short /name, like pulling a recipe card from the box when you decide to cook that dish. A skill is an ability Claude can reach for on its own when the job fits, like a specialist on call whose card is already in the head chef’s hand, and because a skill loads only when it is needed it can carry a lot of detail without weighing down every conversation.

It is the on-demand cousin of the project memory above. CLAUDE.md is always on, read every time, so it holds the rules that always apply. A command or a skill stays out of the way until its moment, so it holds the know-how you only sometimes need.

Say it another way

Two ways to save a job you do a lot:

A command is a recipe card you keep in the box. It does nothing until you reach in and pull it by its short name, then it runs the steps you saved. You decide when.
A skill is like a specialist cook on call. You do not fetch a card, you just say what you want and the head chef recognises it is a job for that specialist and brings them in. That specialist also carries a whole binder of notes and only opens the page they need, so a skill can hold a lot of detail without cluttering everything else.

So the question is simple: do you want to call it yourself, which is a command, or have the AI reach for it when it fits, which is a skill?

Two ways to package a job you do often. A command is a recipe card you pull by name when you decide to cook that dish. A skill is a specialist Claude calls on its own when the job fits, and it can carry a lot because it loads only when it is needed.

What a skill actually looks like

This is the top of the shape+build+launch skill in vibe2value/claude-plugins on GitHub, the one you can install and run. Notice how much work the description is doing: that is the part Claude reads to decide whether this skill fits the moment, before it loads any of the body.

---
name: shape-build-launch
description: Guide building software with AI using the vibe2value
  shape+build+launch framework. Make each decision sharp before writing
  code: decide what to make (Shape), build it (Build), put it in front of
  people (Launch). Use whenever someone is building with AI and needs to
  decide what to make, build it, or launch it.
---

# Shape, Build, Launch

With AI, writing the code is no longer the hard part. The hard part is
judgement: knowing what to ask for, what to leave out and how to tell good
output from output that only looks good.

Your job: make the next decision sharp before any code is written.

The description ends with a plain "use whenever" clause. That is the boundary condition, and it is what gets a skill picked over a similar one, so it is worth more care than the name.

Doing this with Claude Code: Commands and skills

Package a job once, then either call it yourself or let Claude reach for it. Decide by who should trigger it and how much it needs to carry.

A command for a shortcut you trigger. A short saved prompt you call by /name when you want it. Best when you are the one who decides the moment.

A skill for an ability Claude reaches for. Described so Claude can pick it on its own when the job fits, and it can bundle a lot of detail that loads only when needed. Best when you want the AI to notice the moment, not you.

Personal or shared. Keep either just for yourself so it follows you across every project, or put it in the repo so the whole team gets it too.

On-demand, unlike CLAUDE.md. The project memory above is always on, read every time. A command or skill stays out of the way until its moment, so it is where the know-how you only sometimes need belongs.

Common questions

What actually gets a skill chosen?
The description does the heavy lifting. Claude scans the descriptions up front to work out which skill fits the moment, and only then loads that skill's body to follow it. So the description gets it picked and the body does the work.
Why can a skill carry so much more detail than a command?
Because a skill loads only when it is needed. It can bundle reference material that stays out of the way until that job comes up, where anything always-on costs context on every single prompt.
How do I stop a skill reaching further than its job needs?
Name the tools it is allowed to use. It is an allowlist rather than a blocklist, so anything you did not grant is already off-limits and a new or risky tool cannot sneak in by default.
Why is an allowlist the safer shape?
Because you set the boundary by naming what is in, rather than trying to name everything you want to keep out. A read-only summary skill given only read tools simply has no way to delete anything.
Does the argument hint validate what I type?
No. It is a hint to you, the person invoking it, not a validator. It does not check or require anything, it just shows what inputs the thing expects so you are not left guessing.
When should a skill run off to the side rather than in my conversation?
When the work is messy, either because the doing is verbose or the exploring wanders. The test is simple: do you need the journey or just the destination? Only the destination means send it away.
If I copy the team's skill and tune it, do the two stay linked?
No. Your version is a whole standalone copy rather than an overlay, so nothing flows through from one to the other. If the team improves theirs later, yours has no idea.
So how do I choose between a rule file and a skill?
One question: should this always apply, or only sometimes? A universal standard that is true every conversation belongs in the always-on file. Anything only relevant to certain tasks belongs in a skill.

Back to For developers. The craft around it is Working with AI.