Claude Code commands: the full list, and the ones that make it behave

Search "Claude Code commands" and you get the same list every time: /clear, /compact, /model, and a few dozen more, copied straight off the docs. It is useful, and it answers the wrong question. Those commands control the tool. They do not change how the agent behaves the moment you ask it to build something. This is a reference to both kinds, the built-ins that drive the tool and the custom ones that drive the work, and an argument for why the second kind is where nearly all the leverage lives.

What are Claude Code commands?

Claude Code commands are typed shortcuts that start with a slash. There are two kinds, and the difference matters more than any single command. Built-in slash commands ship with Claude Code and control the session itself: clearing context, switching models, editing memory. Custom commands are ones you write, a small markdown file that becomes a reusable workflow you trigger by name. Built-ins control the tool. Custom commands control the work.

The built-in Claude Code commands worth knowing

Most people install Claude Code and use maybe ten percent of it. Here are the built-ins that actually earn their keep, grouped by the job they do. Claude Code moves fast, so treat this as the map and run /help for the exact syntax on your version.

One more that is not a slash command but belongs here: press Shift+Tab until the input says plan. Claude reads and proposes the whole change without editing a file, and you approve first. It is two minutes that saves hours of building the wrong thing, and it is the single best habit a beginner can pick up.

How to write your own custom command

This is the part the listicles skip, and it is the whole point. Drop a markdown file at .claude/skills/<name>/SKILL.md describing the steps you want, and it becomes /<name>. Claude can also invoke it on its own when the moment fits. Personal commands live in ~/.claude/skills/. Check the project ones into git and your whole team gets the same workflow, no copy-paste, no re-explaining. A command is just a good habit, written down once where the agent will actually read it.

The commands that control the agent, not the tool

Here is the argument. The built-in commands are table stakes. The reason your agent still over-builds, still guesses, still says "this should work" about code it never ran, is that none of the built-ins touch its behavior. Behavior is set by the custom commands you give it, or by the ones you never bothered to write.

That is exactly what kitstarter is: a set of custom commands that make the agent behave like a careful builder instead of a fast one. Each is a real workflow, not a prompt you paste. Here is what the set does.

• /start interrogates you with clarifying questions until the goal is genuinely clear, then writes a short plan and a CLAUDE.md and waits for your yes. Ask first, build second.
• /step builds one step of the plan at a time, with a checkpoint after each one actually works. Small, safe, reversible.
• /check proves a change works by really running or opening it, and reports what it saw. The end of "this should work."
• /fix finds the real cause before changing anything, instead of piling patch on patch.
• /review reads the actual diff with fresh eyes against the original goal, and flags what is risky, half-done, or off-scope.
• /secrets catches leaked API keys, exposed .env files, and secrets in frontend code before anything goes public.
• /ship gets it live: deploys, sets production environment variables, and hands back a working URL.
• /recover gets you back to a working state when something broke badly or git turned scary, without making it worse.
• /polish fixes the things that make a screen look AI-made, by root cause, not by decoration.

Notice what they have in common. Every one of them is a rule about when to stop and what not to do, which is the part the default agent has no opinion about. That is the same idea behind the five archetypes of AI engineering: the skill is not producing more output, it is holding the agent to the value function the moment actually calls for.

Built-ins control the tool. Custom commands control the agent.

Learn the built-in commands once. They make you faster at driving Claude Code, and /clear, /compact, and plan mode alone will change your day. But the list of built-ins is not what separates people who get clean, shippable work from people who get confident slop. That gap is behavior, and behavior is a set of custom commands. You can write them yourself, one careful habit at a time, or you can install a set that already encodes them. Either way, the commands that matter are the ones that make your agent ask before it builds and stop when it is done.

Common questions

What are the built-in Claude Code commands? Typed shortcuts that start with a slash and control the session: context (/clear, /compact, /context), memory (/memory), models and config (/model, /config, /output-style), and automation (/hooks). Run /help for the exact list on your version.

How do I create a custom slash command? Make a file at .claude/skills/<name>/SKILL.md with the steps you want. It becomes /<name>. Personal ones go in ~/.claude/skills/; commit the project ones so your team shares them.

What is the difference between a command and a skill? Two views of one thing. The skill is the SKILL.md file with the instructions. The command is how you trigger it, by typing /name.

What are the best commands to start with? /clear and /compact for a clean context, plan mode before big changes, then custom behavior commands: one that asks before building, one that proves a change runs, one that reviews the diff against the goal.