Claude Code Commands: The Ones I Actually Use

I’ve been running Claude Code as my main coding tool for most of the past year. Most of the work I do at RightBlogger and on the small product sites I run goes through it at some point. There are around 80 built-in commands at this point, but the actual list I touch in a given week is much smaller.

This is that list, plus an honest section on --dangerously-skip-permissions, which is the flag everyone wants to know about and almost nobody uses correctly.

How commands work in Claude Code

Inside a session, type / to see every command available, or type / followed by a few letters to filter. A command is only recognized at the very start of your message; anything after the command name is passed as arguments.

Two things to know up front. First, slash commands and skills now use the same system. The official commands reference splits them into “built-in commands” (behavior coded into the CLI, like /clear and /model) and “bundled skills” (prompt-driven, like /simplify and /debug), but you invoke both the same way. If you put a file at .claude/commands/deploy.md or a skill at .claude/skills/deploy/SKILL.md, both create /deploy.

Second, not every command shows up for every user. Availability depends on your plan, OS, and environment. /desktop only shows on macOS and Windows. /upgrade only shows on Pro and Max plans. If a command in this post isn’t there for you, that’s why.

Everything below is from the official commands reference and the permissions docs, tested against Claude Code 2.1.114.

The ones I run constantly

These are the ten or so commands that earn their muscle memory.

Context management: /clear, /compact, /context

/clear starts a new conversation with an empty context. The previous one stays available in /resume. Aliases: /reset, /new.

/compact [instructions] is different. It keeps the same conversation but summarizes it to free up context. Pass focus instructions if you want the summary biased toward something specific. Use this when you’re mid-task and the context bar is getting hot.

/context shows current context usage as a colored grid, with suggestions for what’s eating the most. I use it whenever a session starts feeling sluggish to figure out which tool or memory file is bloating things.

Sessions: /resume, /branch, /rewind

/resume [session] (alias /continue) jumps back into a previous conversation. With no argument, it opens a picker.

/branch [name] creates a branch of the current conversation at this point. You can explore one approach, then /resume back to the branch point and try a different one without losing the original. Alias: /fork. (If you set the CLAUDE_CODE_FORK_SUBAGENT env var, /fork instead spawns a forked subagent and stops being an alias for /branch.)

/rewind is checkpointing. Roll back the conversation, the code, or both, to a previous point, or summarize from a selected message. Aliases: /checkpoint, /undo. This one feels weird the first time and indispensable after.

Models and effort: /model, /effort

/model [model] switches the model for the session. With no argument, it opens a picker.

/effort [level] controls how much reasoning the model uses. Accepts low, medium, high, xhigh, or max. max is session-only, and the available levels depend on the model you’re on. Run with no argument to get an interactive slider. Both of these take effect immediately, without waiting for the current response to finish, which is the kind of small detail you only appreciate after living without it.

Diffs and reviews: /diff, /review, /security-review

/diff opens an interactive diff viewer for uncommitted changes and per-turn diffs. Left and right arrows switch between the current git diff and individual Claude turns; up and down browse files. This is what I use to actually read what just happened before I trust it.

/review [PR] reviews a pull request locally in the current session. For deeper cloud-based reviews there’s /ultrareview, but that one runs against your account billing and isn’t something Claude can launch on its own.

/security-review analyzes pending changes on the current branch for things like injection, auth issues, and data exposure. Worth running before any PR that touches request handling.

File access: /permissions, /add-dir

/permissions (alias /allowed-tools) opens an interactive dialog for managing allow, ask, and deny rules. You can view rules by scope, add or remove them, and review recent auto-mode denials. This is the single command most worth learning if you want to stop being prompted for the same Bash variations forty times a day.

/add-dir <path> adds a working directory for file access during the current session. Worth knowing: most .claude/ configuration in the added directory is not loaded as configuration, just as files. The exceptions are skills in .claude/skills/, which do get picked up with live reload.

The ones worth knowing exist

These don’t earn daily slots, but they’re the ones I reach for when the situation calls for them.

/init initializes a project with a CLAUDE.md guide. Set CLAUDE_CODE_NEW_INIT=1 for an interactive flow that also walks through skills, hooks, and personal memory files.
/memory edits CLAUDE.md files, enables or disables auto-memory, and views auto-memory entries.
/agents manages subagent configurations.
/plan [description] enters plan mode directly from the prompt. Pass a description to start with that task immediately, like /plan fix the auth bug.
/simplify [focus] is a bundled skill that reviews recently changed files for code reuse, quality, and efficiency, then fixes what it finds. Spawns three review agents in parallel and aggregates their findings.
/debug [description] enables debug logging for the current session and troubleshoots issues by reading the session debug log. Worth knowing that debug logging is off by default unless you started with claude --debug, so running /debug mid-session captures logs from that point forward, not earlier.
/loop [interval] [prompt] runs a prompt repeatedly while the session stays open. Omit the interval and Claude self-paces. Example: /loop 5m check if the deploy finished.
/schedule [description] (alias /routines) creates, updates, lists, or runs scheduled remote agents. Useful for the “remind me to clean up that feature flag in two weeks” pattern.
/usage (aliases /cost, /stats) shows session cost, plan usage limits, and activity stats.
/export [filename] exports the current conversation as plain text. With a filename, writes directly; without, opens a copy/save dialog.
/copy [N] copies the last assistant response to the clipboard. Pass N to copy the Nth latest. With code blocks present, you get an interactive picker. Press w in the picker to write the selection to a file instead, which is genuinely useful over SSH.
/mcp manages MCP server connections and OAuth.
/plugin manages plugins. /reload-plugins reloads all active plugins to apply pending changes without restarting.
/doctor diagnoses your Claude Code installation. Press f to have Claude fix any reported issues.
/insights analyzes your sessions and reports on project areas, interaction patterns, and friction points.

The dangerous one

Now the section everyone scrolls to: --dangerously-skip-permissions.

This is a CLI flag, not a slash command. You start a session with it:

claude --dangerously-skip-permissions

It puts the session in bypassPermissions permission mode, which skips all the per-tool approval prompts. No more “Allow Bash to run npm install?” No more accept-edit dialog. Claude just goes.

There’s also a related flag, --allow-dangerously-skip-permissions, that doesn’t enable bypass mode but allows it as an option (so you can flip into it with --permission-mode bypassPermissions later). Anthropic recommends the latter only for sandboxes with no internet access.

What it actually skips

According to the permissions documentation, bypassPermissions mode skips all permission prompts, including writes to .git, .claude, .vscode, .idea, and .husky. Those are the directories most people assume are protected and aren’t.

That means if you’re running this in a real project, Claude can rewrite your local git history, edit your editor settings, modify your husky hooks, and overwrite your own .claude/ config without asking. None of those will trigger a prompt.

What it doesn’t skip

There is one circuit breaker. Removals targeting the filesystem root or your home directory, like rm -rf / or rm -rf ~, still prompt regardless of the mode. The docs frame this as a guard against model error, not user error. So you’re not going to wipe your machine in a single tool call without seeing a dialog first.

Hooks are also still respected. A PreToolUse hook that exits with code 2 still blocks the call. So if you have your own guardrails wired up, they keep working.

When I actually use it

My honest take: with a strong model like Claude Opus 4.7, this flag is more usable than its name implies. Opus is unlikely to wander off and do something catastrophic on its own. I do run sessions with bypass mode on for routine work where I’m watching what’s happening, and the friction reduction is real.

The risk isn’t the model freelancing. The risk is one bad prompt from you. Ask Claude to “clean up that directory” ambiguously, drop bypass on, and you can lose work. Tell it to “reset the database” without specifying which one, and it’ll happily run the destructive command against whatever connection your local env is pointed at. Worst case, a single typo or unclear instruction in a bypass session can delete files you care about, drop a database, or do something genuinely worse if the session has access to production credentials. The flag removes the safety net that would have caught any of that.

So a better framing than “never use it” is: use it with a strong model, in a project where you’ve thought about the blast radius, and only after you trust yourself to write prompts that are unambiguous about destructive operations. The rules I run with:

Don’t run bypass mode in a directory holding uncommitted work I’d hate to lose.
Don’t run bypass mode in any session that has access to a production database, S3 bucket, or live API key.
Never paste a prompt I haven’t read carefully into a bypass session.
Anthropic’s own recommendation, “isolated environments like containers or VMs where Claude Code cannot cause damage,” is still the safest bar to hit when the project allows it.

If those constraints don’t fit a particular project, the lower-risk paths below get you most of the friction reduction without the full liability:

/permissions to allow specific commands you trust. Spend ten minutes setting up Bash(npm run *), Bash(git status *), Bash(jest *), and the prompts go away.
The /fewer-permission-prompts skill, which scans your transcripts for common read-only Bash and MCP calls and adds a prioritized allowlist to your project’s .claude/settings.json.
/sandbox to toggle sandbox mode (on supported platforms). When sandboxing is enabled with autoAllowBashIfSandboxed: true (the default), sandboxed Bash commands run without prompting. The sandbox boundary substitutes for the per-command prompt, which is a much safer trade than blanket bypass.
acceptEdits mode, which auto-accepts file edits and common filesystem commands like mkdir, touch, mv, and cp for paths in your working directory. Most of the friction without most of the risk.

How orgs lock it down

If you run a team and don’t want anyone using bypass mode, set permissions.disableBypassPermissionsMode to "disable" in managed settings. That blocks the mode regardless of what individual users put in their own settings. The --dangerously-skip-permissions flag will still parse, but the mode won’t activate. Worth setting if Claude Code is going on company laptops with access to anything sensitive.

Custom commands are just skills now

If you find yourself pasting the same instructions into chat, or your CLAUDE.md file has grown a section that’s really a procedure, that procedure should be a skill.

The minimum is a directory with a SKILL.md file. Drop it at ~/.claude/skills/<name>/SKILL.md for personal use across every project, or .claude/skills/<name>/SKILL.md for a single project. The directory name becomes the command. Add YAML frontmatter with a description, and Claude can also load the skill automatically when the description matches what you’re asking.

A useful pattern is the ! prefix to inject live shell output into a skill before Claude reads it:

---
description: Summarize uncommitted changes and flag risky ones.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the diff in two or three bullets. Flag missing error handling, hardcoded values, or tests that need updating.

When you run /summarize-changes, Claude Code runs git diff HEAD first, replaces the placeholder with the output, and only then sends the prompt. The instructions arrive with the actual diff already inlined.

The full reference is in the skills documentation. I built a few of these for the WordPress sites I run, and the time savings vs pasting the same checklist into chat are real.

Skills worth installing

The good thing about skills being a shared format is you don’t have to write your own to benefit. There’s now a directory at skills.sh where developers publish reusable skills for Claude Code, Cursor, Cline, and other agents. A few I keep installed:

color-expert by meodai. Color naming, theory, palettes, ramps, gradients, conversions, accessibility. The kind of knowledge I don’t want to keep re-explaining to an agent every time I’m picking colors.
emil-design-eng by Emil Kowalski. Encodes Emil’s philosophy on UI polish, component design, animation decisions, and the small details that make software feel good. If you’ve ever stared at one of Emil’s components on Twitter and wondered how he gets motion to feel that way, this is the closest thing to a transferable answer.
make-interfaces-feel-better by Jakub Krehel. Design engineering principles for hover states, micro-interactions, and the kind of polish that takes a UI from working to nice.

If you want to find more, skills.sh itself has a find-skills skill you can install that helps you discover others when you describe what you’re trying to do. Mildly recursive but useful.

Quick reference

If you just want the categorical list:

Context tools: /clear, /compact, /context
Sessions: /resume, /branch, /rewind
Model and effort: /model, /effort, /fast
Reviewing changes: /diff, /review, /security-review, /ultrareview
Permissions and access: /permissions, /add-dir, /sandbox
Project setup: /init, /memory, /agents, /skills, /hooks
Workflow skills: /simplify, /debug, /loop, /schedule, /fewer-permission-prompts
Visibility: /usage, /insights, /status, /doctor
Output: /copy, /export, /recap
Integrations: /mcp, /plugin, /reload-plugins, /install-github-app, /install-slack-app
Session UI: /theme, /color, /focus, /tui, /statusline
The dangerous flag, CLI only: --dangerously-skip-permissions

That’s not all of them. The complete list is in the official commands reference, and it changes often enough that I’d check it before relying on anything not covered here.