Claude Code Commands: The Cheat Sheet I Wish I'd Had on Day One
Claude Code ships with a lot of slash commands, and the in-tool list tells you what each one is but not which ones deserve muscle memory. After months of daily use, my honest split: about eight commands carry the whole workflow, a dozen are situational, and the rest you’ll discover when you need them. Here’s the cheat sheet, plus the feature that beats every built-in — writing your own.
The commands that carry the workflow
/clear — wipe the conversation and start fresh. The single most underused command. Context from your last task actively pollutes the next one (and costs tokens); when you switch tasks, clear. My rule: new intent, new context.
/compact — summarize the conversation and continue from the summary. For long sessions on one task where you need the thread but not the transcript. Claude Code also compacts automatically as context fills, but doing it at a natural pause point beats having it happen mid-thought.
/model — switch models mid-session. Heavier model for the gnarly design step, faster one for mechanical edits.
/permissions — view and edit what Claude may do without asking: allow rules, deny rules, per-tool settings. This is the UI over the same rules that live in settings.json — the deeper dive is in the settings and permissions guide.
/memory — open your memory files (CLAUDE.md and friends) for direct editing. Pairs with the # message prefix, which saves an instruction to memory without opening anything — the two-second habit covered in how Claude Code memory works.
/init — bootstrap a CLAUDE.md for the current repo by having Claude analyze it. A good starting draft — treat the output as scaffolding to prune, per the CLAUDE.md guide.
/agents — manage subagents: specialized assistants with their own prompts and tool access that the main session can delegate to.
/mcp — manage MCP server connections, the plugin system that gives Claude external tools (browsers, databases, APIs).
Situational, but good to know they exist
/cost— usage and spend for the session. Worth a look weekly, not hourly./config— interactive settings editor (theme, notification style, and more)./statusline— configure the terminal status line; surprisingly useful, and its own rabbit hole./hooks— manage lifecycle hooks (run a linter after every edit, block certain commands mechanically)./review— ask for a code review of your current changes./help— the honest fallback: full command list, current as of your installed version — which is why I’m not printing an exhaustive table that would quietly go stale.
Two non-slash tricks that belong on any cheat sheet: ! prefix runs a shell command directly from the prompt (output lands in the conversation), and claude -p "prompt" runs headless — one shot, no session — which is the doorway to scripts and CI.
Custom commands: the actual power feature
Every built-in above is generic. The commands that transform your workflow are the ones you write — and it takes one Markdown file:
- Create
.claude/commands/in your repo (or~/.claude/commands/for personal ones). - Add
deploy-check.mdwith a prompt inside. - Type
/deploy-checkin any session. The file’s content becomes the prompt;$ARGUMENTSinterpolates anything you typed after the command.
That’s it. The filename is the command, project commands are shareable via git, and suddenly your team’s tribal rituals are executable:
# .claude/commands/pr-desc.md
Look at the diff between this branch and main, then write a PR
description with: a two-line summary, a bullet list of changes
grouped by area, and a test plan. Tone: plain, no fluff.
Extra context from me: $ARGUMENTS
The pattern to notice: anything you’ve explained to Claude twice should become either a memory or a command. Facts and rules go to memory; procedures go to commands. A /new-endpoint command that encodes your API conventions does more for consistency than a style guide ever did.
Keeping command sprawl in check
The failure mode of custom commands is the same as every abstraction: you write ten, use three. Start from real repetition — grep your own prompt history for things you’ve typed more than twice. And when a command’s prompt grows past a screen, it probably wants to reference project docs (@docs/...) rather than inline them.
For the pre-session side of this workflow — the design chats and debugging threads in claude.ai where half these procedures get worked out before they’re codified — the usual disclosure applies: we build NorthLab Folders, which keeps those conversations in local, searchable folders across Claude, ChatGPT, and Gemini. It’s where my command drafts live before they become files.
Frequently asked questions
What are Claude Code slash commands?
In-session commands that start with / and control the tool rather than talk to the model — /clear resets context, /compact summarizes it, /model switches models, /permissions edits what Claude may do, /memory opens your memory files. Type / in a session to see the full list with descriptions.
How do I create custom commands in Claude Code?
Drop a Markdown file in .claude/commands/ in your project (or ~/.claude/commands/ for personal, cross-project ones). The filename becomes the command — review.md becomes /review — the file’s content becomes the prompt, and $ARGUMENTS inserts whatever you type after the command. Commit the project folder to share commands with your team.
What’s the difference between /clear and /compact in Claude Code?
/clear wipes the conversation entirely — fresh context, fastest and cheapest, right when switching tasks. /compact summarizes the conversation and continues with the summary, preserving the thread of long work at the cost of detail. Rule of thumb: new task, /clear; same long task, /compact.
How do I run Claude Code without the interactive session?
Use the -p flag for headless mode: claude -p “your prompt” runs one task and exits, which is how people wire Claude Code into scripts and CI. Interactive sessions are for working; headless is for automating.