Inside a session, a message starting with / is not a message to the model. It is an instruction to Claude Code itself.
The list that is always right
Type /help.
That is not a dodge — it is the actual answer. The set of built-in commands grows and changes, and a list printed in a tutorial is out of date the moment the tool ships an update. Your own session knows what your own version has.
Read the list once, properly
Spend two minutes reading /help output on your first day. You do not need to memorise it. You need to know roughly what exists, so that later, when you want a thing, you remember that the thing might exist.
The ones you will actually use
A handful come up constantly:
/help— the list, and the honest answer to “does this tool do X”./init— draft a CLAUDE.md for this project. The previous lesson./clear— wipe the conversation and start fresh, without leaving the project. This is the “start over” from level 2./compact— condense the conversation so far to free up room, keeping a summary./context— see how full the session is. Useful right when things start feeling foggy./permissions— inspect and change what the agent is allowed to do without asking. The next-but-one lesson./mcp— manage connections to outside tools. The next lesson.
Quick check
Your session has gone stale but you want to keep working in this project. Which is the right move?
Saving the requests you keep retyping
There is a second kind of shortcut, and it is one you build yourself.
Some requests you type over and over: a review checklist, a release routine, a way you like bugs investigated. Retyping them from memory means a slightly worse version every time.
Write them down instead. A folder of Markdown files, one per request, each one refined a little every time you use it. Then a session becomes: open the file, paste, go.
Do that in the terminal below — a prompts/ folder with your review prompt in it.
From a file to a real command
Claude Code can also register saved instructions so they show up in the / menu as your own commands, rather than something you paste. The exact folder and file format for that have evolved with the tool, so take them from the current documentation rather than from here — the writing skill is the same either way.
What makes a good saved prompt
- Specific about output. “Point at files and lines” beats “check the code”.
- Scoped. Say what it covers and what it does not.
- Short enough to read before you paste it. If you cannot skim it, you will stop checking whether it still says what you want.
Your review prompt after a month of small edits is a genuinely useful artefact. It is also the only document in your project that improves every time you are annoyed.