I Built 20 Claude Code Commands. I Use Four.

Quick answer

Claude Code commands are custom slash commands: markdown files you drop in .claude/commands/ that expand into a saved prompt when you type /name. They are great for the two or three prompts you retype every day. As of July 2026 the honest advice is not "collect more of them." I built about twenty over a few months and use four. This is a field note on which ones earned the slash, which ones I deleted, and the newer question that actually matters: when a command should have been a skill instead.

I keep seeing the same post. "50+ Claude Code commands you are not using." "16 commands that changed my workflow." I read all of them, copied a pile into .claude/commands/, and then watched myself use almost none of it.

So this is the opposite article. Not a list to add. A count of what survived contact with real work, on one real repo, since spring 2026.

Everything below is Claude Code on a mid-size Next.js app I ship to actual users. n=1. Your repo will disagree with mine in places, and that is the point.

What a command actually is

A Claude Code command is a plain markdown file. Put review.md in .claude/commands/ and typing /review pastes that file's contents in as your prompt. That is the whole mechanism. There is no magic.

Two things are worth knowing on day one:

• $ARGUMENTS. Anything you type after the command name gets substituted where you write $ARGUMENTS in the file. So /scope add rate limiting to the login route sends the file with that phrase spliced in. This is the difference between a command that is a static wall of text and one that is actually reusable.
• Project vs personal. .claude/commands/ lives in the repo and gets committed, so the whole team shares it. ~/.claude/commands/ is yours across every project. I keep team conventions in the repo and my own muscle-memory shortcuts in the home folder. Mixing them is how you end up with nine slightly different /test commands.

That is it. The docs list more surface area, but the mental model is: a command is a prompt you saved because you were tired of typing it.

The four I actually kept

After the collecting phase burned off, four survived. What they have in common: I reach for each one at least a few times a week without thinking, and each replaced a prompt I was genuinely retyping.

/scope takes a one-line feature request and makes Claude Code write the plan before touching code. The file is basically: "Given $ARGUMENTS, list the files you will change, the order, and the risks, then stop and wait." It exists because handing a vague task straight to an agent is how you get a fast, confident, wrong diff. Making it think out loud first is the single highest-leverage command I have.

/review is my pre-commit read. It asks for a diff review focused on the three things I actually miss: error handling on the new paths, anything that widened a type to any, and dead code left behind. Not a generic "review this." The specificity is why I trust the output.

/test-this points at the current file and asks for the two or three tests that would actually catch a regression, not a suite of trivial ones. $ARGUMENTS lets me say /test-this focus on the empty-cart case.

/ship is the boring one and maybe the most used: draft the commit message and PR description from the staged diff, in the terse style I like, no marketing language. It saves ninety seconds every single time, which adds up more than any clever command does.

Notice none of these are exotic. They are the prompts I typed most, frozen.

The graveyard

Honest part. Things I built, felt clever about, and abandoned:

• /explain to summarize unfamiliar code. Deleted, because I just ask in plain language and it works the same. A command added friction, not speed.
• /refactor with a long opinionated style rubric. Deleted, because a good refactor is too context-dependent to freeze into one prompt. Every time I used it I ended up over-steering.
• /standup to summarize what I did yesterday from git log. Cute. Used it twice. It was solving a problem I did not really have.
• A /commit that also auto-committed. Fast, and exactly the kind of thing that commits a debug console.log for you. I moved that logic to a hook instead and killed the command. More on why below.

The pattern in the graveyard: every dead command was either (a) a thing I do rarely, or (b) a thing too situational to template. Frequency and stability are the whole test.

The question the listicles skip: command or skill?

Here is the 2026 wrinkle, and it is why "collect more commands" is dated advice.

Claude Code now has skills as well as commands, and they are not the same tool wearing two names. The distinction that finally made it click for me:

• A command is something you invoke, deliberately, by typing /name. It is a saved prompt.
• A skill is a capability the agent reaches for on its own when the task calls for it, without you naming it.

Once I had that framing, half my .claude/commands/ folder looked wrong. My /refactor rubric did not want to be a command I remember to run. It wanted to be standing context the agent applies whenever it refactors, which is closer to a skill, or honestly just a few lines in CLAUDE.md. Meanwhile /ship is correctly a command, because I want it to fire only when I say so, at the end, never mid-task.

The test I use now, before building anything:

1. Do I want to trigger this myself, every time? If yes, command. If I want it to happen automatically when relevant, it is a skill or standing memory, not a command.
2. Is it a fixed prompt, or a judgment call? Fixed and repeated: command. Situational judgment: leave it to the model with good context.
3. Would I be annoyed if it ran without me asking? If yes, it has to be a command. /ship yes. A formatter, no, that belongs in a hook.

That third question is the same restraint I ended up at with Claude Code hooks and with subagents I kept or deleted: the lifecycle matters more than the cleverness. A command, a skill, a hook, and a line in CLAUDE.md can all technically do the same job. The right one depends entirely on who should pull the trigger and when.

Setting them up without the mess

If you want the short version:

• Make .claude/commands/ in your repo. One file per command, named thing.md, invoked as /thing.
• Use $ARGUMENTS in any command that takes input. Static commands age badly.
• Keep team commands in the repo, personal ones in ~/.claude/commands/.
• Write the command as the prompt you already type, not an aspirational one. If you have not typed it three times this week by hand, do not freeze it yet.

And prune. Every month or so I open the folder and delete anything I have not used since the last cleanup. A commands folder is like a CLAUDE.md file or a bloated AGENTS.md: the value is in what you left out.

Verdict

Commands are worth it for the small number of prompts you genuinely repeat. Four of them, in my case. The mistake almost everyone makes, me included, is treating the folder as a collection to grow instead of a set of shortcuts to earn. Add a command the third time you retype a prompt, not the first time you read about one. And before you build it, ask whether it even wants to be a command, or a skill, or just a sentence of context the agent already has.

Fewer, sharper, and pruned often. That has held up better than any list of fifty.