Claude Code Slash Commands for Beginners

The first thing most people do in a new Claude Code session is type a forward slash to see what happens. A menu drops open with dozens of entries, most of which mean nothing yet, and the usual move is to dismiss it and go back to typing sentences. That menu is worth ten minutes, because fifteen or so of those entries are the controls for your whole session.

This guide covers the ones that earn their place on day one, grouped by the job they do instead of listed alphabetically. Then it covers the part the big command roundups miss: the skills you write yourself land in that same menu, and you can call them by name.

What happens when you type a slash

A slash command is a message that starts with a forward slash. You type it in the same box as everything else, but it does not travel to the model as an ordinary request. Claude Code intercepts it and handles it itself: clearing the transcript, opening a picker, printing a report about the session you are in.

That explains a behavior beginners find odd. Asking Claude in plain English to clear the conversation gets you a friendly reply and no clearing, because the model has no hands on the session controls. Typing /clear does the actual thing. A few of the bundled commands (/doctor and /code-review among them) are built as skills that Claude then carries out with its own tools, but you type all of them the same way, at the start of your message.

Finding your feet: /help, /context, /model

Start with /help. It prints the commands your install actually has, which matters because that list is not the same everywhere: plugins add entries, and so do your own skills. Any list you read online, this one included, is a snapshot of someone else’s setup.

/context is the command beginners rarely find on their own and then use constantly. It reports what is currently taking up the context window. That window holds a good deal more than your chat: your CLAUDE.md loads into every session, a short description of every skill Claude can see is always present too, and then come the files you have opened and the conversation itself. When answers start feeling forgetful, /context tells you whether the window is genuinely filling up or whether something else is going on. /model shows and changes the model this session runs on.

Managing the session: /clear, /compact, /resume, /rewind

/clear starts the conversation over. /compact, in practice, condenses what has happened so far and keeps going. /resume reopens an earlier session so you can pick a thread back up, and the command line has claude -r for the same job before a session starts. /rewind takes the session back to an earlier point. That last one is worth trying in a throwaway project first, so you know exactly what it restores before you need it under pressure.

Clear or compact: the distinction that costs you

Beginners get this one wrong in both directions, and both directions are expensive.

/clear drops the conversation. Everything you established in this session is gone: the file you explained, the naming decision you made, the three approaches you already ruled out. What survives is everything that loads fresh in any session anyway, meaning your CLAUDE.md and your skills. Reach for it when you are genuinely switching tasks. A clean window for a new job is both cheaper and more accurate than dragging an unrelated hour behind you.

/compact keeps the thread. It condenses the conversation so far into a shorter form and continues from there, so continuity survives while the token count drops. Reach for it when you are still on the same task and running out of room: mid-refactor, mid-debug, mid-migration.

The failure modes are symmetrical. Clearing mid-task means re-explaining everything you just explained, and you will not remember all of it. Compacting when you should have cleared means carrying a summary of the last problem into the next one, where it quietly colors every answer. So the question to ask is not how full the window is. It is whether you are still on the same task.

Setting up a project: /init and /memory

Run /init the first time you open Claude Code in a repository. It generates a starting CLAUDE.md: a Markdown file Claude reads at the start of every session in that project, holding the standing facts you want followed every time, such as the build and test commands and the conventions of the codebase. /memory is the in-session entry point to those memory files. What belongs in CLAUDE.md versus what belongs in a skill is its own question, and a companion guide comparing CLAUDE.md, skills, subagents, and hooks is linked at the end.

Seeing what you have, and what is broken

Four commands answer one question: what can this session actually reach? /skills lists the skills Claude can see right now, personal, project, and plugin-provided ones together. /agents lists your subagents, which are separate assistants with their own context window that Claude can hand a side task to. /mcp shows your Model Context Protocol connections, the servers that let Claude reach systems outside your filesystem. /plugin opens a panel for browsing, installing, and managing plugins, which install a whole bundle at once: skills, subagents, hooks, and MCP servers. Hooks are shell commands Claude Code runs itself at fixed lifecycle points regardless of what the model decides, and the companion guide linked at the end compares them with skills properly.

Two more for when something is off. /doctor is the bundled health check for your install and configuration. /permissions is where you review and adjust what Claude is allowed to do without asking, and it is worth opening once early rather than in the middle of a problem. Recent Claude Code versions start interactive sessions on paid plans in an automatic permission mode, where a classifier reviews actions instead of prompting you for every edit, so knowing where that dial lives is useful. Shift+Tab cycles through the permission modes.

Your own skills are slash commands too

Here is the part that changes how you use both. Claude Code folded custom slash commands and skills into a single mechanism. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both give you /deploy, and both behave the same way when you type it. The older commands files still work, but the skill form is the one that gets bundled scripts and reference files, progressive loading, and the extra controls below. If the same name exists in both places, the skill wins.

The consequence for you is that writing one skill gives you two doors into the same procedure. Claude can reach it on its own by matching your request against the skill’s description, and you can reach it explicitly by typing its name.

Two situations make the explicit form the right one. The first is certainty. Some procedures have to run: a deploy checklist, a review gate. Do not leave those to intent matching. Type the name. The second is debugging: invoking by name gives you a signal about the skill itself, separate from whether the trigger fired. That is the control test near the top of the guide on fixing a skill that will not trigger, linked at the end.

Two switches in a skill’s frontmatter sharpen each side. Frontmatter is the small YAML block at the top of SKILL.md, between two lines of three dashes, where a skill declares its name, its description, and its settings; what belongs in there is its own lesson, also linked at the end. Setting disable-model-invocation to true means only you can invoke the skill and Claude never triggers it on its own, which is what you want on anything with side effects. Setting user-invocable to false does the opposite, hiding the skill from the slash menu so only Claude reaches it. Recent versions also let you stack up to six skills in one message. Skills can declare argument handling in frontmatter as well, so text typed after the name lands in named slots, but that is past day one and this guide does not cover those fields.