OCDevel
WalkPodcast
The logo for OCDevel Claude Code features clean, modern typography paired with minimalist developer-centric iconography representing the Claude command-line interface.
OCDevel Claude Code Podcast
The OCDevel Claude Code Podcast is a technical show for software developers using Anthropic's Claude Code CLI and developer tools in production. Over a structured 30-episode series, the show teaches you how to move from running a single manual terminal session to orchestrating fully automated pipelines. Learn how to configure CLAUDE.md, manage permissions in settings.json, build custom slash commands, connect MCP servers, and set up autonomous review-and-fix loops. Subscribe to learn how to build a system where Claude safely implements features, runs tests, and deploys to production for you.
CTA
Generated with OCDevel PodcasterMade with OCDevel Podcaster
This show was made with OCDevel Podcaster — turn any topic or text into an AI-narrated podcast episode that drops right into your feed.Turn any topic into an AI-narrated episode in your feed.Create your own →Create your own →

Built-in slash commands and the keyboard habits that make a session fast

2h ago

A tour of the commands that ship in the box, the four steering keys you will use every run, and the decision you make constantly: clear versus compact, plus how to spot when compaction silently drops the context you were relying on.

Show Notes

Episode three of the OCDevel Claude Code arc, and the first one that's purely about speed. You can already drive a session from episodes one and two. This one makes you fast: the commands that ship in the box, and the keyboard moves you stop thinking about.

What we cover:

  • The reframe. On the 2.1 line, custom slash commands have been merged into skills, so the / menu is now one surface mixing built-in commands, bundled skills and workflows, your own skills, plugin commands, and MCP prompts. Type / to see exactly what your install has, since a command is only recognized at the start of a message and availability varies by plan and platform. See the commands reference.
  • The catalog, grouped by when you reach for it — setup (/init, /memory, /config), steering (/model, /effort, /plan, /context), review (/diff, /code-review, /review, /security-review, /simplify), the between-sessions family (/clear, /resume and its alias /continue, /branch, /rename, /export), recovery (/rewind, /doctor), and cost (/usage, aka /cost).
  • The everyday decision: /clear vs /compact. Clear starts a fresh conversation (the old one parks in /resume); compact keeps the thread and replaces verbatim history with a steerable summary. The rule: clear for unrelated work, compact to keep going. Details in exploring the context window and managing costs.
  • The pitfall: silent context loss. Auto-compaction keeps intent and key snippets but drops full tool outputs and intermediate reasoning, and path-scoped rules are lost until a matching file is read again. How to recognize the drift and stay ahead of it with /context and focused compaction.
  • The safety net and its blind spots. /rewind (or double-Escape) restores code and conversation, but bash side effects aren't tracked. Checkpoints are local undo; git is permanent history. See checkpointing.
  • The keyboard. The four steering keys (Escape to interrupt, double-Escape to rewind, Shift+Tab for modes, Ctrl+C), history recall with Ctrl+R, the fast-input symbols (@ files, ! shell, # memory, / commands), plus /btw for a tool-less side question. Reference: interactive mode.

Recency note for mid-2026: /vim moved into /config → Editor mode (removed in 2.1.92), /cost is now an alias for /usage, and the auto-compact threshold is version-dependent. Verify against /help in your own install.

Next episode: writing your own custom slash commands.

Transcript

Last time we made one session safe. We set up settings.json, we scoped permissions so Claude isn't asking you to approve every single shell command, and we learned plan mode, the look-before-you-leap toggle. Before that, episode one, we covered the core loop and project memory, CLAUDE.md, init, and how to resume a session. So you can already drive Claude Code. You can start it, point it at a repo, and get real work done.

This episode is about getting fast. Not new capabilities, just fluency. The commands that ship in the box, and the keyboard moves you'll reach for so often they stop being conscious decisions. By the end of this you should be steering a session the way you steer your editor, without looking at your hands.

Let me start with a reframe, because it changes how the whole menu makes sense.

In the older versions of Claude Code there was a clean split. Slash commands were one thing, skills were another. That split is gone. As of the two-point-one line, custom slash commands have been merged into skills. A file at dot-claude, commands, deploy-dot-markdown, and a skill at dot-claude, skills, deploy, SKILL-dot-markdown both create the same slash-deploy command, and they behave the same way. Your old command files keep working, nobody broke them, but the mental model is now unified.

So when you type a forward slash in Claude Code, you're looking at one surface that mixes several kinds of thing. There are built-in commands, where the behavior is actually coded into the command-line tool itself. There are bundled skills, prompts that Anthropic ships and that Claude can also invoke on its own when a task matches. There are bundled workflows that fan work out across subagents in the background. And then there's your own stuff, your skills, plugin commands, and prompts exposed by connected MCP servers. We're focused on the built-ins today. Skills and custom commands and hooks each get their own episode later in this act. But it helps to know that the slash menu is one door into all of it.

Two disclaimers straight from the Claude Code commands reference that will save you confusion. First, a command is only recognized at the very start of your message. Anything you type after the command name gets passed to it as arguments. You can't bury a slash command in the middle of a sentence and expect it to fire. Second, not every command shows up for every person. Availability depends on your platform, your plan, and your environment. So if I mention something today that you don't see, that's expected, and the move is to check your own install rather than assume it's broken.

That's the single most useful habit in this whole episode, actually, so let me make it the first real move. To see what you've got, type a forward slash on an empty prompt. Claude Code shows you every command available to you, and if you keep typing letters it filters the list live. That menu is the truth for your machine, your version, your plan. The tool moves fast enough that any catalog, including this one, is a snapshot. Commands get renamed, merged, and occasionally removed between versions. So the meta-move is, type slash and look, or run slash-help, which the docs describe simply as show help and available commands. When you forget what's there, that's the command.

One more bit of notation before the tour. In the docs, when you see an argument in angle brackets, that argument is required. When it's in square brackets, it's optional. I'll mostly skip that detail out loud, but it's why some commands do something useful with no arguments at all, and others need you to hand them something.

Okay. Let me walk the catalog the way the docs themselves organize it, which is by where you are in a normal day's work rather than alphabetically. That ordering is worth adopting because it maps to muscle memory.

When you first sit down in a repo, you're in setup mode. This is mostly episode-one and episode-two territory, so I'll go quickly. Slash-init writes a starter CLAUDE.md for the project. Slash-memory opens your memory files, lets you turn auto-memory on or off, and shows you what auto-memory has been quietly recording. Slash-mcp manages your connections to MCP servers and their sign-in. Slash-agents manages subagent configurations. Slash-permissions, which we lived in last episode, manages your allow, ask, and deny rules, and it has an alias, slash-allowed-tools, if that name is stuck in your fingers. And slash-config, also reachable as slash-settings, opens the settings interface for theme, model, output style, and the rest.

Hold on slash-config for a second, because there's a gotcha hiding in it. If you're a Vim person and you go looking for a slash-vim command to turn on modal editing, it's not there anymore. It was removed in version two-point-one-point-nine-two. Vim editing now lives inside slash-config, under Editor mode. So the command you half-remember was real, it just moved. That's a theme today.

One more setup command that's easy to miss, slash-add-dir, followed by a path. It adds another working directory so Claude can read files outside your current project root during this session. The catch worth knowing, most of your dot-claude configuration is not picked up from that added directory. It's there for file access, not for loading a second project's rules.

Now you're actually working, and you want to steer the model. This is where a few commands really earn their place.

Slash-model, optionally with a model name, switches which model you're talking to and saves it as your default for new sessions. With no argument it opens a picker. There's a nice detail here, on a model row you can press the s key to switch for just the current session instead of changing your default. And on models that support effort levels, the left and right arrows adjust how hard the model thinks. One thing the picker will warn you about, if your conversation already has a bunch of output in it, switching models asks you to confirm, because the next response has to re-read the full history without the cached context it had before. The switch applies immediately though. You don't have to wait for the current response to finish.

Right next to that is slash-effort, which takes a level, low, medium, high, x-high, max, or the one called ultracode. Max and ultracode are session-only, they won't stick as your default. No argument opens a slider. The reason you care about this in everyday work is cost and speed. You dial effort down for grunt work and up for the gnarly reasoning, and you'll feel both your latency and your bill respond.

Slash-plan, optionally with a description, drops you straight into plan mode from the prompt. So instead of toggling and then typing, you can say slash-plan, fix the auth bug, in one move. Plan mode itself we covered last time, this is just the express lane into it.

Then there are two commands about the context window itself, and these are the heart of the episode, so I'm going to name them here and come back to them properly. Slash-context visualizes where your context is going, as a colored grid. And slash-compact frees up room by summarizing the conversation so far. Park those. We're going to spend real time on them.

When you're getting ready to ship, there's a cluster for reviewing your work. Slash-diff opens an interactive diff viewer. It's better than it sounds, because the left and right arrows let you flip between your current git diff and the diff from each individual turn Claude took, so you can see exactly what changed on which step. Slash-code-review is a bundled skill that reviews the current diff for correctness bugs plus cleanup opportunities, things like duplicated logic you could simplify. You can pass it an effort level, and two useful flags, dash-dash-fix to actually apply what it finds, and dash-dash-comment to post the findings as inline comments on a GitHub pull request. Slash-review, with a pull request number, reviews a PR locally inside your session. Slash-security-review looks specifically at your pending changes for security problems, injection, auth holes, data exposure. And slash-simplify, in recent versions, is a cleanup-only pass, it runs several agents in parallel hunting for reuse and simplification but explicitly does not look for correctness bugs. For bugs, that's slash-code-review. Keep those two straight, one finds what's broken, the other finds what's ugly.

Then the family that matters most between sessions, and this is the one people tangle up, so let me slow down. These are the commands for moving between conversations.

Slash-clear starts a brand new conversation with empty context. And here's the part everyone misreads, it does not destroy the old conversation. The previous one stays available in your resume picker. What clear wipes is the live context, not your history and not your project memory. CLAUDE.md is still there. It has a couple of aliases, slash-reset and slash-new, same thing. Slash-resume, optionally with a session ID or name, brings back a past conversation, or opens a picker if you don't name one. And here's a fact to file away, slash-continue is just an alias for slash-resume. Inside a running session, they do the same job. There's also slash-branch, alias slash-fork, which splits the current conversation at this exact point, moves you into the branch, and keeps the original safe so you can get back to it later through resume. Slash-rename gives the current session a name that shows up on your prompt bar, and with no argument it'll generate a name from your history. And slash-export dumps the current conversation to plain text, either to a file you name or to your clipboard.

There's a small habit buried in there that pays off constantly. The docs flat-out recommend running slash-rename before you run slash-clear. Because once you clear, that old conversation is still alive in the resume picker, but if you never named it, good luck finding it in a list of auto-generated titles three days later. Name it, then clear. Future you will be grateful.

When something's gone wrong, there's a recovery cluster. Slash-rewind, with aliases slash-checkpoint and slash-undo, rolls the conversation, or your code, or both, back to an earlier point. That one's important enough that it gets its own section in a minute. Slash-doctor diagnoses your installation and settings, and if it finds problems you can press f and have Claude try to fix them. Slash-debug turns on debug logging for the current session and reads the log back, which is handy because logging is off by default unless you launched with the debug flag. Slash-feedback, which absorbed the old slash-bug command, is how you report a bug or share a conversation with Anthropic. And slash-status opens the settings interface on the status tab, version, model, account, connectivity, and it works even while Claude is mid-response.

Last cluster, money. Slash-usage shows your session cost, your plan usage limits, and activity stats. On a paid plan it breaks the usage down by skill, by subagent, by plugin, by MCP server, and you can toggle between the last twenty-four hours and the last seven days. Two aliases to know, slash-cost and slash-stats both land you here, slash-cost is literally documented as an alias for slash-usage. One honest caveat from the docs, the dollar figure is a local estimate and may differ from your actual bill. And if you're on a Pro or Max subscription, that session dollar amount isn't what you're paying anyway, you'll mostly care about the plan usage bars, how close you are to your limit.

There's a longer tail of quality-of-life commands, slash-login and slash-logout, slash-terminal-setup for configuring shift-enter and friends in editors that need it, slash-theme, slash-statusline, slash-keybindings, slash-skills to list your skills sorted by how many tokens they cost. You don't need to memorize those. You need to remember that typing a slash shows you all of them.

Now let me make good on the two I parked, because the single most common everyday decision in Claude Code is this one, clear versus compact.

Here's the clean version. Slash-clear is for switching to unrelated work. Slash-compact is for staying on the same work but making room.

Let me make that concrete, because the difference is real and getting it wrong wastes either your tokens or your context. When you run slash-clear, you get a fresh conversation, empty context, and the old one is parked safely in resume. When you run slash-compact, you stay in the same conversation, but Claude replaces the word-for-word history with a structured summary to free up space. You'll see a message that says conversation compacted. The summarizing happens behind the scenes, you don't watch it scroll by. And you can aim it. You can say slash-compact, focus on the auth changes and the failing test, and it'll try to keep that material in the summary.

The docs give you a one-liner for choosing, and it's worth memorizing. To free up context while continuing the same conversation, use compact. To start fresh on something unrelated, use clear. The docs on managing costs put the same advice from the other direction, use clear when you switch to unrelated work, because stale context just wastes tokens on every message you send afterward. So if you finish a bug fix and you're about to start an unrelated feature, that's clear, ideally with a rename first. If you're three files deep in the same feature and the window's getting heavy but you're not done, that's compact.

Now, what does compaction actually keep, and what does it throw away. This is the part that bites people, so I want to be precise about it.

The summary keeps your requests and your intent, the key technical concepts, the files you examined or changed along with important code snippets, the errors you hit and how they got fixed, your pending tasks, and the work currently in flight. What it replaces is the verbatim conversation. As the docs on exploring the context window put it, the full tool outputs and the intermediate reasoning are gone. Claude can still reference the work, but it no longer has the exact code it read earlier. It's reasoning off a paraphrase of that file, not the file.

There's a second layer to this that surprises people, which is how your rules and memory survive a compaction. Your system prompt and output style are untouched, they were never part of the message history. Your project-root CLAUDE.md and your unscoped rules get re-injected from disk, so those come back clean. Auto-memory, re-injected from disk. But, and this is the sharp edge, rules that only load when a matching file is read, the ones with paths in their frontmatter, those are lost until a matching file is read again. Same with a nested CLAUDE.md sitting in a subdirectory, gone until Claude touches a file in that subdirectory again. And invoked skill bodies are kept, but capped, about five thousand tokens per skill and twenty-five thousand total, with the oldest dropped first. The docs put it cleanly, the skill listing is the one exception, only the skills you actually invoked get preserved.

So you can see the shape of the trap forming. Compaction is mostly smart, but it summarizes away exactly the things you might have assumed were always on.

And here's the kicker, you don't always choose when it happens. Claude Code auto-compacts on its own as you approach the context limit. The status line and the context grid will warn you, you'll see something like, context left until auto-compact, some percentage. The exact threshold isn't a clean published number and it shifts between versions and models, it's been reported somewhere in the high eighties to low nineties percent of the window. So treat that as approximate and verify against your own install. If you want to control it, there's an environment variable, CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, that sets the percentage where auto-compaction fires.

There's also a lighter, earlier intervention worth knowing about, sometimes called microcompaction. Before the session gets anywhere near full, Claude Code starts offloading the bulky tool results, the giant outputs, onto disk, while keeping the recent ones inline so reasoning keeps flowing. The older ones become retrievable by path if they're needed again. It's the cheapest cleanup and it runs before full compaction ever kicks in. You mostly won't notice it, which is the point.

Alright, let me turn all of that into the one pitfall you are genuinely going to hit, because I'd rather you recognize it in the wild than memorize a table.

Picture a real debugging session. You're deep in it. Claude has read three files, it's got the exact stack trace in context, you're making progress. You keep going, the window fills up, and auto-compact fires. Or you hit compact yourself at an awkward moment. The summary dutifully keeps your intent and the key snippets, but the full file contents and the step-by-step reasoning are gone. And the next answer drifts. It's subtle. Claude re-asks for something it clearly knew a minute ago, or it suggests a fix that ignores a constraint you established earlier, or it's just vaguer than it was. That drift is the tell. It's reasoning off a paraphrase now, not the real thing.

The sharper version of this trap is the path-scoped rule. Say you've got a coding convention that only loads when a matching file is read. You've been treating it as always-on all session. A compaction happens, and that rule is summarized away. It's silently not applying anymore, and it won't come back until the next time Claude reads a file that matches. So your house style quietly stops being enforced, and nothing tells you. The fix is to move anything you truly want always-on out of a path-scoped rule and into your project-root CLAUDE.md, the one that gets re-injected from disk every time.

How do you recognize you're in this situation. A few tells. You see the conversation compacted notice and the very next reply is worse. The context grid or the status line is creeping toward zero, context left until auto-compact. And honestly, quality often starts slipping before any warning shows up, because degradation begins well before the window is technically full. If you wait for the warning, you've usually waited too long.

So here's how you stay ahead of it instead of getting caught. Be proactive. Glance at slash-context now and then to see where your window is actually going, which tools are eating it. Compact on your own terms, on a clean boundary, rather than letting it fire mid-thought, and a lot of people compact somewhere around half-full rather than waiting for ninety-something percent. When you do compact, steer it, name the thing that has to survive. Prefer clear when the next task is unrelated, so an old task doesn't ride along and get half-blended into the new one. And for verbose, noisy operations, hand them to a subagent so the giant output never enters your main window at all, only the conclusion comes back. That's a later episode, but it's the structural answer to this whole problem.

That brings me to the actual safety net, rewind, because there's a related confusion I want to clear up. People reach for clear when they've made a mess and they want to undo it. But clear does not revert your files. It starts a fresh conversation. Your working tree is exactly as messed up as it was. To actually roll back code, that's a different command.

Slash-rewind, and you can also trigger it by pressing escape twice on an empty prompt, opens a menu that lets you go back to an earlier point in the conversation, or the code, or both. Quick caveat on that double-escape, if there's text in your prompt, double-escape clears the text instead of opening the menu. The cleared text gets saved to your input history though, so you can press up to get it back. The menu only opens on rewind when the input is empty.

How do checkpoints even exist to rewind to. Every user prompt creates a new checkpoint, automatically. They persist across sessions, so you can rewind inside a resumed conversation, and they get cleaned up with the session after thirty days by default. The menu gives you a few choices, restore both code and conversation, restore just the conversation and keep your current code, restore just the code and keep the conversation, or summarize from a chosen point, either compressing everything from here forward or everything up to here. So rewind is really targeted compaction plus a state rollback, you pick the message and you pick which side to act on.

But, and this is critical, rewind has blind spots that can leave your tree in a worse state than you expect. Bash command changes are not tracked. If Claude ran a remove command, or moved a file, or copied something via the shell, rewind cannot undo it. Only the direct file edits Claude made through its own editing tools are tracked. So you can rewind, feel safe, and still be sitting on a deletion that the shell did and rewind never saw. External changes aren't tracked either, your own manual edits in another window, or another session touching the same files. The checkpointing docs say it plainly, think of checkpoints as local undo and git as permanent history. Rewind is not a replacement for version control. The practical habit, commit at meaningful green points, so rewind isn't your only net. If you want to try a genuinely different approach while keeping the original intact, that's not rewind, that's forking, launch with continue and the fork-session flag and you branch off without disturbing the original.

Let me give you one more command that's genuinely useful and under-known, slash-btw. Short for by the way. You use it to ask a quick question about your current work without adding anything to the conversation history. Like, slash-btw, what was that config file called again. What makes it special, it can see your entire conversation, but it has no tools. It can't read files, run commands, or search. It answers purely from what's already in context. It's a single response in a dismissible overlay, it never enters your history, it's cheap because it reuses the parent's prompt cache, and it works even while Claude is busy doing something else, it runs alongside the main turn without interrupting it. The docs on interactive mode have a lovely framing for it, by-the-way is the inverse of a subagent. It sees your full conversation but has no tools, while a subagent has full tools but starts with an empty context. If the answer turns out to matter, you can press f in the overlay to fork it into a real session with full tools, and the original stays parked in resume.

Okay. Let me bring this home with the keyboard, because the commands are half the speed, and the other half is never taking your hands off the home row. One caveat up front, keyboard shortcuts can vary by platform and terminal, and in the fullscreen transcript view you can press the question mark to pull up the full shortcut panel.

There are four steering keys to burn into muscle memory. The first and most important is escape. A single escape interrupts whatever Claude is doing right now, the current response or the current tool call, and crucially it keeps the work already done. This is the habit that separates fast users from slow ones. The moment you see Claude heading the wrong direction, you hit escape and redirect. You do not sit there and watch a wrong plan play out for ninety seconds out of politeness. Interrupt, correct, continue.

Second, double escape, which we just met, opens the rewind menu when the prompt is empty. Third, shift-tab cycles your permission modes, default, accept-edits, plan, and whatever else you've enabled. That's your fast toggle into and out of plan mode, the thing we set up last episode, no command needed. And fourth, control-c, which interrupts a running operation, and if nothing's running, the first press clears your input and a second press exits Claude Code. Contrast that with control-d, which is a clean exit straight away.

Then there's recall, because retyping is wasted time. The up and down arrows walk your command history, with one wrinkle, in a multi-line prompt they first move the cursor, and only once you're already at the top or bottom edge do they start walking history. Your history is stored per working directory and it resets when you run clear. Even better is control-r, reverse search through your history. Hit control-r, start typing, and it finds matching past prompts, hit control-r again to cycle to older matches. There's a neat extra, control-s cycles the search scope, this session, this project, or all projects. One naming note, control-r is history search now. The old job that used to live on control-r, toggling verbose output, moved to control-o.

Now the fast-input symbols, three of them, and they're the difference between a clunky session and a smooth one. The at sign triggers file-path autocomplete, so you type at, start typing a filename, and reference that file right in your prompt instead of describing it. The exclamation mark drops you into shell mode, you prefix your input with it and the command runs directly, without Claude interpreting or approving it. Exclamation, npm test. Exclamation, git status. The output gets added to your conversation context, which is the point, you're showing Claude the result. And the hash, the pound sign, at the start of a line is the quick way to jot a note into your project memory. At sign for files, bang for shell, hash for memory, slash for commands. Four symbols, and between them you rarely need to leave the prompt.

A few more that earn their keep. Control-o toggles the transcript viewer, the detailed view of every tool call, useful when you want to expand something like, called the browser three times, into what actually happened. Control-t toggles the task list. Control-l redraws the screen when your terminal gets garbled, without losing your input. And control-g opens your current prompt in your real editor, the one in your EDITOR variable, which is the move when you're writing a long, structured, multi-line instruction and the single-line prompt is fighting you.

On multi-line, since it trips people up, a backslash then enter always gives you a newline, and control-j always works too with no configuration. Shift-enter works natively in a bunch of terminals, iTerm2, WezTerm, Ghostty, Kitty, Warp, Apple Terminal, Windows Terminal, and for the editor terminals, VS Code, Cursor, Windsurf, and a few others, you run slash-terminal-setup once to wire it up. And to paste an image, it's usually control-v, not your system paste, which is a surprise the first time, it drops in an image chip you can reference by position.

A couple of nice automatics you don't have to do anything to get. Claude Code shows a grayed-out suggested prompt sometimes, seeded from your git history and the conversation, and you accept it with tab or the right arrow. And when you come back after stepping away for a few minutes, you'll get a one-line recap of where things stood, or you can ask for one any time with slash-recap.

Let me tie the whole thing together into one loop you can actually adopt, start to finish.

You sit down and pick up the most recent session in this repo with claude dash-c. If it's a new, unrelated task in an existing session, you rename the old one and then clear. You set your altitude, shift-tab into plan mode for anything non-trivial, dial effort up or down depending on how hard the thinking is. You work fast, at-sign to point at files, bang to run a quick shell check without leaving the prompt, control-r to pull back a prompt you wrote yesterday. The instant it heads wrong, escape, you don't wait. When you need a fact without polluting the thread, slash-btw. You keep half an eye on slash-context, and when the current task gets heavy but you're not done, you compact with a focus instruction. When you switch tasks entirely, you clear instead. If something breaks, double-escape to rewind, remembering that anything the shell did isn't tracked, which is why you committed to git at the last green point. Then you ship, slash-diff to eyeball the changes, slash-code-review or slash-review for a pull request, commit. And you check the meter with slash-usage.

None of that is new capability. It's the same Claude Code you've had since episode one. The difference is you're now driving it with your hands instead of with a menu, and you know which way the context window is leaking before it costs you an answer. Next episode we start writing our own, custom slash commands, turning a prompt you keep retyping into a single word.