The Claude Code Cheat Sheet

The four building blocks

Almost every Claude Code setup is some arrangement of these four. Knowing which one a problem belongs to is most of the work.

CLI commands

Everyday

Config & extensions

Background & remote sessions

CLI flags

There are well over eighty. These are the ones that earn their keep.

Scope and permission

Model and effort

Scripting and automation

Slash commands

Context and session

Configuration

Work

Diagnostics

Keyboard shortcuts

Control

Prompt prefixes

Line editing

Vim bindings are available too — turn them on with /vim or editorMode: "vim". NORMAL, INSERT, and visual modes, with text objects and f/t motions.

Settings & precedence

Where settings live, highest priority first

A key set higher wins. Lists — permission rules, claudeMdExcludes — merge across layers rather than overriding.

Keys worth knowing

The full list runs to roughly 180 keys, plus a deep sandbox.* tree for filesystem and network isolation. Full reference: settings-reference.

Permissions

Modes

Rule syntax

Rules are Tool or Tool(specifier). They evaluate deny → ask → allow; first match wins, and specificity does not reorder them. A broad deny cannot carry an allowlist exception.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Read(//home/me/project/**)",
      "mcp__github__get_*"
    ],
    "ask":   [ "Bash(git push *)" ],
    "deny":  [ "Read(./.env)", "Edit(./secrets/**)", "mcp__*" ]
  }
}

Wildcards — the part everyone gets wrong

Other things to know: compound commands are split on && || ; | & and each part must match on its own; wrappers like timeout, nice, and bare xargs are stripped before matching, but npx, docker exec, and devbox run are not; a bare tool name in deny removes the tool from Claude's context entirely, while Bash(rm *) leaves Bash available and blocks matching calls.

Hooks

Shell commands fired at lifecycle events, configured in any settings file. Claude Code passes a JSON payload on stdin; your exit code and stdout JSON decide what happens next.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit|Bash",
        "hooks": [
          { "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard.sh" }
        ]
      }
    ]
  }
}

Exit codes

The events you'll actually use

There are 33 events in total, covering task lifecycle, config and file changes, worktrees, model switches, MCP elicitation, and instruction loading. Full list: hooks reference.

Skills

A folder with a SKILL.md. Keep the body under about 500 lines and push detail into sibling files — Claude loads them only when it needs them.

my-skill/
├── SKILL.md        # overview + navigation
├── reference.md    # loaded on demand
├── examples.md
└── scripts/helper.py

Where they live

Enterprise beats personal beats project. Skills override same-named files in .claude/commands/.

Frontmatter

Arguments and variables

Live context injection

Backtick-bang runs a shell command before Claude sees the skill, and substitutes the output. This is what turns a static template into something that reacts to the repo.

---
description: Summarize uncommitted changes and flag anything risky.
allowed-tools: Bash(git *)
---

## Current changes
!`git diff HEAD`

## Instructions
Summarize the diff in three bullets, then list the risks.

Non-zero exit aborts the invocation; there's a two-minute timeout per command; disableSkillShellExecution turns the whole mechanism off.

Subagents

Markdown with frontmatter, in .claude/agents/ or ~/.claude/agents/.

---
name: code-reviewer
description: Reviews code for quality and best practices.
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. Analyze the code and give specific,
actionable feedback on quality, security, and correctness.

Frontmatter

Built in

Invoking

# let Claude route by description — say it plainly
Use the test-runner subagent to fix the failing tests

# force a specific one
@agent-code-reviewer look at the auth changes

# run a whole session as one
claude --agent code-reviewer

MCP servers

# HTTP, the common case
claude mcp add --transport http notion https://mcp.notion.com/mcp

# with a static token
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer $GITHUB_PAT"

# local process over stdio
claude mcp add --transport stdio jobs -- node mcp/jobs-server/index.js

# inspect and authenticate
claude mcp list
claude mcp login sentry

Scopes

.mcp.json

{
  "mcpServers": {
    "jobs": {
      "type": "stdio",
      "command": "node",
      "args": ["mcp/jobs-server/index.js"]
    },
    "api": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${API_TOKEN}" },
      "timeout": 600000
    }
  }
}

${VAR} and ${VAR:-default} expand in command, args, env, url, and headers. Transports: stdio, http, sse (deprecated), ws.

CLAUDE.md & memory

Load order, broadest first

Files are concatenated, not overridden, from the filesystem root down to your working directory. Files in subdirectories load when Claude reads files there.

Rules

Split large instruction sets into .claude/rules/*.md. A rule with paths: frontmatter loads only when Claude touches matching files, which is how you keep a monorepo's context bill down.

---
paths:
  - "src/api/**/*.ts"
---

# API rules
- Every endpoint validates its input.
- Use the standard error response shape.

Practical limits

If an instruction must hold every single time, it is not a CLAUDE.md line. It is a hook.

CLAUDE.md arrives as a user message after the system prompt. Claude reads it and tries to follow it — there is no compliance guarantee, especially where two files disagree. Run /context to confirm what actually loaded, and /memory to edit it.