You use four Claude Code commands. Ten are missing

You can work well with Claude Code knowing very little: you write what you want, you approve what it does, and when the conversation gets long you type /clear. That is enough for an ordinary day.

The ten commands in this article are not extra features. Each one solves a problem you are already having, even if you have not put it into words: the conversation that fills up and gets expensive, the setup you never did, the change that went wrong, and the work that does not fit into a single turn.

They are grouped by that problem, not in alphabetical order.

Context: what costs you most without you seeing it

This group saves the most money and is the worst understood.

Claude Code has no memory between messages. Every time it answers, the whole conversation is sent again: your messages, its replies, and the contents of every file it read along the way. On turn twenty you are not paying for one message; you are paying for the sum of everything before it.

That explains something that puzzles people: a short question in a session that has been open for hours costs considerably more than the same question in a fresh one.

/context — see where the space went

It draws a coloured grid of what is loaded right now, broken down by origin: the system instructions, your CLAUDE.md, the MCP tools, the files that were read, the conversation. It also flags what is surplus: tools that take up a lot, bloated memory, and warnings when you are near the limit.

It is the only one of the ten that does nothing. It only shows. And it is the one worth running first, because the other two in this group are decisions you make by looking at that number.

/compact — summarise without losing the thread

It takes the conversation so far and replaces it with a summary. Useful when you need to keep going on the same topic but the context has filled up.

It accepts instructions about what to keep, and they are worth using:

/compact keep the code examples and the architecture decisions

What survives compaction is defined: your CLAUDE.md and the project memory are loaded again from disk, and of the files that were read, the five most recent are re-read. Everything else goes through the summary.

The detail almost nobody knows: compacting costs money. To summarise the conversation it has to read all of it, so compacting a large context is itself a large request. It is not free.

/clear — start over, and it costs nothing

It starts a new conversation with an empty context. Unlike /compact, it costs nothing: there is nothing to read and nothing to summarise.

From that comes the most useful rule of the three:

• Same topic, and you need what was already discussed → /compact
• Different task → /clear

It is almost always the second one. You just finished fixing a bug and now you are going to write a new function: nothing from the previous conversation is worth what it costs to drag along, and on top of that it competes for the model’s attention with what matters now.

You can pass it a name to find that session later, and come back with /resume.

The two you set up once

/init — let the project explain itself

It creates a CLAUDE.md file at the root with what needs to be known about the project: how it builds, how it is tested, what conventions it has. That file is loaded into every session, so you stop having to explain it each time.

One warning worth more than the command itself: that file is paid for in every session, including the ones that have nothing to do with what it says. Keep it short and put in only what Claude cannot work out by reading the code. The folder structure can be worked out; that the tests run with an unusual command cannot.

/permissions — stop approving the same thing twenty times

It opens a panel for managing what is allowed, what gets asked about and what is denied. You can see the rules by scope — this machine, this project, all of them — and add or remove them.

It is the command that removes the most friction per minute invested. If you are approving npm test for the fifteenth time, that is where it gets fixed.

One practical detail: you can run it while Claude is working, and the change applies from the next tool it uses, in the same turn. There is no need to wait for it to finish.

When something goes wrong

/rewind — go back

It opens with the command or by pressing Esc twice with an empty input. It shows the list of messages you sent; you pick a point and decide what to restore:

• The code and the conversation
• Only the conversation, leaving the files as they are
• Only the code, keeping what was discussed
• Summarise from here or up to here, which is a /compact aimed at one part

This is what to use when Claude took a wrong turn and dragged three files along with it.

And here are the limits, which matter more than the feature. It does not revert anything a terminal command did: if Claude ran rm, mv or cp, that is not undone. It also does not revert what a background subagent did, or changes you made yourself outside the session.

In other words: it undoes file edits made within the session, and nothing else. It is not a replacement for git. The real safeguard is still committing often.

/doctor — check the installation

It runs a checkup of the environment and offers to fix what it finds: duplicate installations, PATH problems, malformed configuration files, outdated versions.

The interesting part is what it checks beyond that. It looks for skills, MCP servers and plugins you have installed and do not use, and compares them with what they cost you in context. It also flags hooks that run slowly, and reviews your CLAUDE.md: it removes duplicates and trims what Claude could work out by reading the code.

It reports its findings first and asks for confirmation before changing anything.

When the work does not fit in one turn

These two are the least known and the ones that change how you work the most.

/goal — work until a condition holds

You define a completion condition and Claude keeps working on its own, turn after turn, until it is met:

/goal all tests in test/auth pass and the lint step is clean

At the end of each turn, a different, smaller model checks whether the condition holds. If it does not, Claude starts another turn instead of handing control back to you. The goal clears itself when it is met, when the evaluator judges it impossible, or when something fails that you have to fix yourself.

The part that decides whether this works well is how you write the condition. The evaluator does not run commands or read files: it only judges what Claude left visible in the conversation. That is why “all tests pass” works — Claude runs the tests and the result ends up written down — and “the code is tidy” does not.

A condition that holds up has three parts: a measurable end state, how to prove it, and what must not change on the way there. And it is worth putting a ceiling on it, something like or stop after 20 turns.

/loop — repeat every so often

It repeats an instruction while the session stays open:

/loop 5m check whether the deploy finished

If you leave out the interval, Claude decides on its own how often to come back.

The difference from /goal is what triggers the next turn: in /loop it is the clock, in /goal it is that the condition is not met yet. To wait on something external — a build, a deploy — use /loop. To finish a piece of work, /goal.

And one to know where you stand

/usage — what you spent and on what

It shows the session’s consumption and, if you are on a plan, how much of the limit you have used. But what pays off most is the breakdown: it attributes recent usage to skills, subagents, plugins and each MCP server separately, with its percentage.

That is where you discover that an MCP server you installed a month ago and never used again is taking a share of the total.

It also flags behaviours accounting for more than 10%, such as long context or cache misses. d and w switch between the last 24 hours and the last 7 days.

The figures come from the local session history on that machine, so they do not include what you did on another computer.

Where to start

If you are going to adopt two, make it these:

/context, once, to see where you are starting from. Without that number, everything else is guesswork.

/clear between tasks. It is free, it is the easiest to adopt, and it makes the most difference over a long day.

The rest come in on their own when the problem each one solves shows up. Which is exactly why it is worth having read about them beforehand: not to remember the syntax, but to remember that they exist.