The Claude Code Cheat Sheet: Every Command, Shortcut, and Config Template That Actually Matters

A working reference for engineers who use Claude Code daily: the keyboard shortcuts worth memorizing, the built-in commands grouped by what you are actually doing, copy-paste-ready config files, and the one decision tree that ends most of your friction.

In this article: This is the Claude Code cheat sheet, distilled. You get the keyboard shortcuts that pay for themselves, the full built-in command catalog organized by purpose, production-ready templates for settings.json, CLAUDE.md, path-scoped rules, and a custom subagent, plus a decision tree that answers the single most common question: "Claude did something wrong. What do I change?" Bookmark it. You will come back.

You have used Claude Code, Anthropic's agentic coding tool, for a few weeks now. You know the agentic loop. You have a CLAUDE.md. You have felt the difference between a session that goes well and one that fights you. And yet, every time you need the exact JSON shape for a permission rule, or the precise frontmatter for a path-scoped rule, or which command summarizes context versus which one clears it, you stop and re-derive it. That re-derivation tax is small per instance and enormous in aggregate.

This Claude Code cheat sheet exists to kill that tax. It is the lookup table: every shortcut, every command, the sample files, and the decision tree, in one place. The rest of any good Claude Code guide teaches you why each artifact exists and how it behaves. This is the page you keep open while you work.

A note on terminology before we dive in, because two ideas recur throughout. Context is the operating system: everything Claude knows in a session, from your files to your rules to the conversation, lives in a finite context window, and managing it is the core skill. And the three-phase agentic loop, "gather context, take action, verify," is the cycle Claude runs on every task. Both ideas shape why these commands and files are designed the way they are.

Keyboard shortcuts worth memorizing

You do not need all of these on day one. You need maybe five. But the five compound, because they remove friction from the actions you take dozens of times an hour.

Shortcut	What it does
Shift+Tab	Cycle permission modes (default, acceptEdits, plan, auto, bypassPermissions). The single most-used key in Claude Code.
Esc (twice)	Open the rewind menu. Restore code, conversation, or both to an earlier checkpoint. Same as /rewind.
Ctrl+G	Open the current prompt or plan in your $EDITOR for multiline editing. The right move for long prompts.
Ctrl+O	Show diagnostics from code-intelligence (LSP) plugins: type errors, lint warnings, findings inline.
Ctrl+T	Toggle the in-session task list view. Shows up to 5 tasks at a time.
Ctrl+R	Search command history, like bash or zsh.
Ctrl+C	Cancel the current generation. Interrupts a long response without exiting the session.
Ctrl+D	Exit the session cleanly.
Ctrl+L	Clear the visible terminal output. Purely visual; it does not affect context.
\ + Enter	Insert a literal newline in your prompt for multiline input.
Cmd/Ctrl+Esc	Launch Claude Code from the current file in VS Code.

There are a few desktop-app and agent-team additions on top of that working set: Cmd/Ctrl+N opens a new session in a new worktree, Cmd/Ctrl+\ closes the focused pane, Ctrl+Tab and Ctrl+Shift+Tab cycle through parallel sessions in the sidebar, and Shift+Down cycles through teammates so you can message one directly during agent-team work.

One trap worth flagging loudly. In Claude Code v2.0 and later, Tab is the thinking-mode toggle, not file completion. File completion happens inside @ references: type @src/ and then Tab for path completion. If you never use thinking mode, you can disable the binding in settings, but most people just learn the new muscle memory.

Every built-in command, grouped by purpose

Type / in any session to filter the full list. Memorizing the alphabet of commands is pointless. Memorizing them by what you are doing when you reach for one is not. Below, the catalog is grouped by intent. Entries marked [Skill] are bundled prompt-based skills; the rest are built-in commands.

Daily diagnostics and navigation

These are the lookups you run several times a day.

Command	What it does
/help	Show all available commands. Type / plus letters to filter.
/context [all]	Visualize what is in the context window as a colored grid. The first move when something seems off.
/memory	List loaded CLAUDE.md, CLAUDE.local.md, and rules files. Toggle auto memory on or off.
/skills	Show available skills from project, user, and plugin sources.
/agents	Manage custom subagents. Create new ones with AI assistance.
/hooks	Show active hook configurations.
/mcp	Manage MCP server connections, see status, approve project-scoped servers.
/permissions	Open the resolved allow, deny, and ask rules and edit them.
/doctor	Automated diagnostic. Press f to have Claude fix reported issues.
/status	Show active settings sources, including managed settings.
/config	Open the settings interface (theme, model, output style). Alias: /settings.

Conversation hygiene

Because context is the operating system, the commands that keep it clean over a long day are not optional housekeeping. They are how you stay fast.

Command	What it does
/clear	Start fresh: clear conversation history but keep project memory.
/compact [focus]	Summarize older messages while preserving important context. Optionally pass focus instructions.
/rewind	Open the rewind menu. Restore code or conversation to a checkpoint. Aliases: /checkpoint, /undo.
/btw <question>	Ephemeral side question. Does not enter conversation history. Read-only, single-turn, low-cost.
/branch [name]	Create a named branch of the conversation at this point. Alias: /fork.
/copy [N]	Copy the last assistant response (or the Nth-latest) to clipboard.
/recap	Generate an on-demand session summary.

Session and state

How you move between, name, and reopen sessions.

Command	What it does
/resume	Reopen a previous conversation from this machine's local history.
/continue	Continue the most recent session. As of v2.1.144 it shows background sessions marked bg.
/rename	Set or change the current session's name.
/tasks	List and manage scheduled tasks and background sessions.
/teleport	Pull a cloud Claude Code session into this terminal. Alias: /tp.
/background [prompt]	Detach the current session to run as a background agent. Alias: /bg.
/desktop	Continue the current session in the Claude Desktop app. Alias: /app.

Project setup and workflow

The commands you reach for when you start something substantial.

Command	What it does
/init	Generate a starter CLAUDE.md. The right first command in a fresh repo.
/plan [prompt]	Generate a one-shot plan without entering plan mode interactively.
/plugin	Manage plugins: install, enable, disable, browse the marketplace.
/effort [level|auto]	Set model effort (low, medium, high, xhigh, max, or auto). No args opens a slider.
/model	Switch between Claude models for the session.
/sandbox	Toggle sandbox mode.

Verification and review

These close the third phase of the agentic loop: verify.

Command	What it does
/review [PR]	Local code review pass. Single-pass, runs in your session.
/security-review	Bundled skill for security-focused review.
/ultrareview	Cloud-based multi-agent review for substantial changes. 5-10 minutes, free first runs, then roughly $5-20 in credits.
/diff	Open the interactive diff viewer for uncommitted changes and per-turn diffs.
/pr	Create a PR for the current branch. Requires the gh CLI.

Autonomous work

The commands that let Claude keep working without you typing every prompt. All four are bundled skills.

Command	What it does
/goal <condition>	Set a completion condition; Claude works until a small fast model confirms it holds. /goal clear cancels.
/loop [interval] [prompt]	Run a prompt repeatedly: on a fixed schedule, self-paced, or with a built-in maintenance prompt. Alias: /proactive.
/batch <instruction>	Decompose a large change into 5-30 independent units, spawn one subagent per unit in isolated worktrees, each opens a PR. Requires a git repository.
/simplify [focus]	Spawn parallel review agents (code reuse, quality, efficiency) over recent work and apply fixes.

Troubleshooting, escalating in order

When something does not work, escalate in this sequence: /doctor first (it diagnoses installation, settings, MCP servers, and context usage; press f for Claude to fix). Then /debug [description], a bundled skill that enables debug logging and diagnoses using the log output; this is the right move when Claude Code itself misbehaves. Then /less-permission-prompts, a skill that scans transcripts for common read-only calls and proposes an allowlist. Finally /feedback, which reports a bug with session context attached. For sharing, /export saves the conversation as Markdown. For account management, /login and /logout.

That is the working set. A handful of niche commands (terminal-setup helpers, internal diagnostics) are not listed; type / and filter to discover anything else.

The settings.json template you should steal

Here is a sensible default .claude/settings.json for a typical project. The shape matters more than the exact commands; adapt the test, lint, and build entries to your stack.

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read", "Glob", "Grep", "Edit", "MultiEdit",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "WebFetch(domain:docs.our-internal-api.com)"
    ],
    "ask": [
      "Write",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(git checkout:*)",
      "Bash(npm install:*)",
      "Bash(npm run deploy:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(sudo:*)",
      "WebFetch(domain:*)"
    ]
  },
  "env": {
    "EDITOR": "code --wait"
  }
}

The logic behind the three lists is the whole point.

• allow covers safe daily operations: reads, edits, and your test, lint, and build commands. These run without interrupting you.
• ask covers operations with consequences: file creation, commits, pushes, dependency changes, deploys. Claude pauses for your confirmation.
• deny covers genuinely dangerous operations that should never run automatically: recursive deletion, force push, hard reset, arbitrary downloads, root commands.
• The combination of WebFetch(domain:*) in deny with a specific domain in allow is the canonical pattern for restricting fetches to a trusted whitelist. Deny everything, then allow the one host you trust.

Keep defaultMode at "default" (explicit approval per operation) until you have built an allow list you genuinely trust, then switch to "auto".

The CLAUDE.md skeleton

CLAUDE.md is the project memory file Claude loads at the start of every session. A good one has five sections. Replace the placeholders with your specifics, and keep the whole file under 200 lines.

# Project: <Your Project Name>

## Overview
Brief description: what this project is, the stack, key dependencies.
Two or three sentences, enough that a new collaborator orients quickly.

## Build, test, and run commands
The exact commands to validate work, in the order you would run them.
- `pnpm install`: install dependencies
- `pnpm test`: run the test suite
- `pnpm run lint`: run lint checks
- `pnpm run typecheck`: TypeScript type-checking
- `pnpm run build`: production build

## Conventions
Project-specific rules every session should follow. Short and specific.
- All API errors return `{ error: string, code: string }`, never raw exceptions.
- Auth uses RS256 JWTs, not HS256.
- Migrations live in `db/migrations/` and run via `pnpm run db:migrate`.

## Never do this
Things that have caused problems before. Be specific.
- Never modify `src/generated/`; those files are produced by codegen.
- Never commit `.env.local` or `config/secrets/*`.
- Never use raw SQL string concatenation; use the query builder.

## Key files
The files Claude should look at first for context.
- `src/api/router.ts`: top-level route definitions
- `db/schema.ts`: database schema
- `docs/architecture.md`: system architecture overview

If your CLAUDE.md grows past 200 lines, that is a signal, not a milestone. Promote stack-specific guidance into path-scoped rules.

Path-scoped rules: guidance that loads only when relevant

A path-scoped rule is a Markdown file in .claude/rules/ with a paths field. It loads into context only when Claude touches matching files, which keeps your operating system (the context window) lean. Here is .claude/rules/python.md:

---
paths: ["**/*.py"]
---

# Python conventions

## Tooling
- Use `ruff` for formatting and linting. Run `ruff check --fix` before done.
- Type hints required for all public functions. Run `mypy --strict` to verify.
- Tests use pytest. Test files mirror source: `src/foo.py` -> `tests/test_foo.py`.

## Style
- Prefer `pathlib.Path` over `os.path`.
- Use f-strings; avoid `.format()` and `%`-formatting.
- Type hints use modern syntax: `list[int]`, not `List[int]`.

## Patterns to avoid
- Do not catch bare `Exception` unless at the top of a request handler.
- Do not use `assert` for runtime checks in production code.
- Do not use mutable default arguments.

The paths field uses gitignore-style glob syntax. It supports globs like **/*.py and brace expansion like src/**/*.{ts,tsx}. A rules file with no paths field loads unconditionally, exactly like CLAUDE.md.

A custom subagent: the second-opinion reviewer

A subagent runs in its own fresh context window, which makes it ideal for a review pass that is not biased by the conversation that wrote the code. Save this as .claude/agents/code-reviewer.md:

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code
  for quality, security, and maintainability. Use immediately after
  writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---

You are a senior code reviewer ensuring high standards of code
quality and security.

## When invoked
1. Run `git diff` to see recent changes.
2. Focus on modified files; treat unchanged files as context only.
3. Begin review immediately without asking for direction.

## Review checklist
- Code is clear and readable; functions and variables well-named
- No duplicated code
- Proper error handling, no swallowed exceptions
- No exposed secrets, API keys, or credentials
- Input validation at trust boundaries
- Good test coverage for the changed behavior
- No obvious N+1 queries or quadratic loops on large inputs

## Output
Provide feedback organized by priority:
- **Critical issues (must fix)**: bugs, security risks, broken contracts
- **Warnings (should fix)**: maintainability, missing edge cases
- **Suggestions (consider improving)**: style, optimizations

Reference file:line for every finding. If no issues are found at a
priority level, say so explicitly, because silence is ambiguous.

Two details carry the weight. The description uses "Proactively" and "Use immediately after writing or modifying code." Both are signals that tip Claude's classifier toward delegating to this subagent automatically. And the tools field restricts it to read-only access. A reviewer that cannot edit is a reviewer you can trust to only review.

The decision tree that ends most friction

This is the single most-bookmarked artifact in any Claude Code reference, and it answers one question: "Claude got something wrong, or I want something different. What do I change?"

The instinct is to reach for whatever tool you used last. The discipline is to match the fix to the failure mode. Walk the tree.

In prose, the same logic, step by step:

1. Claude refused or did not try? Check permissions. If an operation was denied, add it to permissions.allow. If a skill or subagent did not trigger, the fix is the description field, not the permissions: make it more specific and add "use proactively" phrasing.
2. Claude tried but got it wrong, and the rule applies project-wide? Put it in CLAUDE.md at the project root.
3. Wrong, and the rule is path-specific (Python conventions, frontend rules)? Use .claude/rules/<topic>.md with paths: [...] frontmatter.
4. Wrong, and the rule is personal, not for the team? Use CLAUDE.local.md, which is gitignored.
5. Wrong, and it is a procedure you will trigger by name? Use a skill at .claude/skills/<name>/SKILL.md.
6. Wrong, and it must be enforced deterministically, not just suggested? Use a hook in .claude/settings.json.
7. Wrong, and the fix is "do this work in a separate context"? Use a subagent at .claude/agents/<name>.md.
8. The whole setup should travel with the project or to other teams? Package it as a plugin under plugins/<name>/ with a .claude-plugin/plugin.json.

The principle underneath is simple: each layer addresses a different failure mode. Permission rules answer "can Claude do this at all?" CLAUDE.md and rules are guidance Claude reads. Skills are named procedures Claude follows. Subagents are fresh-context delegates. Hooks are deterministic enforcement. Plugins are packaged distribution.

The classic mistake is reaching for a hook when you need guidance, or guidance when you need a hook. "Claude keeps suggesting tabs when we use spaces" is a CLAUDE.md fix; it is a preference Claude should know. "Claude keeps editing the generated/ directory" is a hook fix; guidance can be missed, but a deterministic block cannot. Same symptom shape, opposite tools, because the failure modes differ.

The reference links worth bookmarking

The Anthropic docs evolve faster than any guide can. When this article and the docs disagree, trust the docs. These are the durable entry points:

• Core concepts: How Claude Code works, Memory and CLAUDE.md, Skills, Subagents, Hooks, Permissions.
• Operating: Commands reference, CLI reference, Settings, Debug your configuration.
• Workflows: Plan complex changes, Keep Claude working toward a goal, Code Review, GitHub Actions.
• Plugins and platforms: Plugins, Plugins reference, Platforms and integrations, VS Code.
• Building on Claude Code: Headless mode, Agent SDK overview, Costs.

Do this today

Three concrete moves to make this Claude Code cheat sheet useful immediately, not someday.

1. Bookmark this page, especially the decision tree. It is the lookup you will run dozens of times. The shortcuts and the command catalog come next. Re-deriving any of these from memory is wasted effort once you have a tab open.

2. Copy the settings.json template into a project right now. Swap the test, lint, and build commands for your stack. Even with zero further customization, the three-list structure (allow the safe, ask on the consequential, deny the dangerous) gives you a sane baseline that most projects never bother to set up.

3. Walk the decision tree on one real friction. Pick something specific you have felt this week: "Claude keeps doing X" or "Claude won't do Y." Walk the tree from the top. If the right answer is obvious within 30 seconds, the tree is doing its job. That is the test, and it almost always passes.

The cheat sheet is scaffolding, not the skill

A reference like this is a strange thing to end a guide on, because it is the least conceptual chapter and the most useful one. That tension is the point.

The shortcuts, the command catalog, the sample files: none of them are the skill. The skill is the working knowledge that tells you when a compact beats a clear, why a path-scoped rule belongs in .claude/rules/ instead of bloating CLAUDE.md, and which failure mode you are actually staring at when something goes wrong. This cheat sheet is the scaffolding that holds that knowledge up. It exists so you never have to hold the exact JSON shape of a permission rule in your head, which frees that head for the judgment calls that genuinely require you.

Keep the page open. Walk the tree when you are stuck. And remember the one line that makes all of it cohere: match the fix to the failure mode, not to your reflex.

---

This is Part 19, the final part, of "Claude Code, Day-to-Day," a 19-part guide to mastering Claude Code for working engineers.