Cheat Sheets

Print this page or keep it open in a tab during development sessions.

Starting Claude Code

All Slash Commands

Type / in the prompt to see the full command menu. Commands are grouped by function below.

Session & Navigation

Code & Changes

Configuration & Display

Permissions & Security

Tools & Integrations

Memory & Project Setup

Account & Monitoring

Remote & Cross-Device

Quick Interactions

Keyboard Shortcuts

General Controls

Model & Mode Switching

Multiline Input

Special Input Prefixes

CLI Flags for Automation

Permission Modes

Claude Code has five permission modes. Cycle between them with Shift+Tab during a session, or set at launch:

--dangerously-skip-permissions

Disables all permission prompts and safety checks. Every tool call executes immediately.

# Basic usage with non-interactive mode
claude -p "refactor the auth module" --dangerously-skip-permissions

# Equivalent alternative
claude -p "query" --permission-mode bypassPermissions

When to use it:

• CI/CD pipelines running in isolated containers
• Automated scripting in sandboxed environments
• Docker containers with restricted filesystem scope
• Devcontainers with no access to production resources

When NOT to use it:

• Your local machine with access to production credentials
• Shared CI runners that can reach production
• Any environment with write access to live databases

Even in bypass mode, writes to .git/, .claude/, .vscode/, and .idea/ still prompt to prevent corruption.

--allowedTools (Safer Alternative)

Pre-approve specific tools instead of everything:

# Only allow reading files and running tests
claude -p "fix failing tests" --allowedTools "Read,Edit,Bash(npm test)"

# Wildcard patterns
claude -p "review code" --allowedTools "Bash(git *),Read"

# Multiple tools
claude -p "update docs" --allowedTools "Read,Edit,Bash(npm run build)"

--disallowedTools

Block specific tools entirely:

claude -p "analyze code" --disallowedTools "Bash,Write"

Common CI/CD Patterns

# GitHub Actions: safe automation with limited tools
claude -p "Fix all ESLint errors in src/" \
  --allowedTools "Read,Edit,Bash(npm run lint*)" \
  --output-format json \
  --max-turns 10

# Fully automated in a container (use sparingly)
claude -p "Run tests and fix failures" \
  --dangerously-skip-permissions \
  --max-turns 15

# Strict pre-approval: auto-deny anything not explicitly allowed
claude -p "Fix TypeScript errors" \
  --permission-mode dontAsk \
  --allowedTools "Bash(npx tsc),Edit,Read"

Other Useful CLI Flags

Permissions in Settings Files

File Locations

Allow, Deny, and Ask

{
  "permissions": {
    "allow": [
      "Bash(npm test*)",
      "Bash(git log *)",
      "Bash(git diff *)",
      "Bash(git status*)",
      "Read",
      "Edit"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Edit(.env)"
    ]
  }
}

Evaluation order: deny > ask > allow. If something matches deny, no other rule can override it.

Pattern Matching

Enterprise: Managed Settings

Admins can enforce rules that developers cannot override:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

IDE Integrations

VS Code

Install “Claude Code” from the VS Code Marketplace. Shares all settings, MCP servers, hooks, and skills with the CLI.

JetBrains (IntelliJ, PyCharm, WebStorm, GoLand)

Install “Claude Code” from the JetBrains Marketplace.

Chrome Integration

Install the “Claude in Chrome” extension. Then use @browser mentions or /chrome to configure.

@browser go to localhost:3000 and check for console errors

Hooks Quick Reference

Hooks are shell commands that execute automatically at lifecycle events. Configure in settings.json. See the full Hooks guide for details.

Key Hook Events

Common Patterns

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
        }]
      }
    ]
  }
}

Custom Slash Commands (Skills)

Create reusable workflows that the team can invoke with /command-name. See the full Skills guide for details.

.claude/skills/my-skill/SKILL.md      # Project scope (shareable)
~/.claude/skills/my-skill/SKILL.md     # Personal scope (all projects)

Invoke with: /my-skill "arguments here"

The $ARGUMENTS variable in SKILL.md receives whatever the user passes.

Context & Session Management

Context is the biggest factor in Claude’s response quality. See the full guide.

The pattern: /clear between unrelated tasks. /compact when context is getting full but you are mid-task. /branch before experiments.

Model Selection & Cost

Match the model to the task. See the full guide.

Cost guardrails for automation:

claude -p "fix test failures" --max-turns 10 --max-budget-usd 5

Images & Screenshots

Claude Code can read images for visual debugging. See the full guide.

[paste screenshot]
The button alignment is off. Fix it in @src/components/Header.tsx

@File References

Use @file when you want Claude to read the file contents immediately. Use prose paths when you want Claude to search for and locate the file itself.

Piping and Chaining

# Pipe a diff for review
git diff HEAD~3 | claude "review these changes for security issues"

# Pipe a file for analysis
cat src/server.ts | claude "find potential memory leaks"

# Pipe error logs
npm test 2>&1 | claude "explain why these tests are failing"

# Chain with other tools
claude -p "generate a SQL query to find duplicate users" | pbcopy

Testing

Write Tests

Write comprehensive tests for src/UserService.java

Write a failing test for: when email is missing @, registration fails

What code paths in InventoryService are not covered by tests?

Write [test framework] tests for [file]. For each public method, test:
- Happy path with valid inputs
- Null/empty/invalid inputs
- Edge cases and boundary conditions
- Error handling when dependencies fail

Match our patterns in [ExistingTestFile].

Run and Fix Tests

Run the test suite

Run just the tests for UserRegistrationService

This test is failing: [paste error]. Read the source and explain why.

Fix the test failure without changing the test — the test is correct.

[Test name] is failing with [error]. Look at the test and the
implementation to find why. Show me the relevant code and the fix.

Code Review

Security Review

Review src/OrderProcessor.ts for SQL injection and auth bypass

Review this code for security vulnerabilities only. For each finding:
1. Show the vulnerable line
2. Explain what an attacker could do
3. Show the fixed code
Categorize as CRITICAL or IMPORTANT. Skip style concerns.

Performance Review

Find N+1 queries and blocking operations in this file

General Review

Review staged changes. Flag anything CRITICAL, IMPORTANT, or MINOR.

Review my changes for security issues, performance concerns, and
convention violations. Reference specific file and line numbers.

Git Diff Review

Review the changes between main and this branch for bugs

Debugging

Targeted Search

Find all places where user input goes directly into SQL queries

Find every empty catch block in the codebase

Diagnosis

Walk me through what happens when transferStock gets insufficient stock

This returns null when it shouldn't. Trace the logic for input X.

We have a bug: [describe symptom]. [Paste stack trace if available].
Investigate the root cause, show me the relevant code, and propose a
fix with a regression test.

Bug Fix Workflow

1. Write a test that reproduces this bug
2. Run it — confirm it fails
3. Fix the code
4. Run it — confirm it passes
5. Run all tests — confirm nothing else broke

Refactoring

Safe Setup

Write characterization tests that capture current behavior of [method]

Common Refactors

Extract the validation logic into a private helper method

Flatten these nested ifs into guard clauses with early returns

Replace the format switch/if chain with a strategy pattern

Replace magic numbers 90, 75, 60 with named constants

Find and remove dead code — methods that are never called

Analyze [file] and propose a refactoring plan that splits it by
responsibility. Constraints: don't change the public API, all existing
tests must pass.

Then one extraction at a time:

Extract [methods] into [NewClass]. Update [OriginalClass] to delegate.
Don't change test files.

Safety Constraints

Don't change any behavior — all existing tests must still pass

Don't fix bugs during this refactoring. Same behavior, better structure.

Building Features

Planning

Read src/services/. I need to add [feature]. Describe your approach first.

Plan how to implement [feature]. Consider our existing patterns in
[directory]. Include: files to create, order of implementation, and
which existing code to reference.

Incremental Building

Just implement the data layer. Don't add the API endpoint yet.

Look at [ExistingFile] and create a [NewFile] that follows the same
patterns for [list specific patterns: injection, error handling, logging].

Following Patterns

Follow the same pattern as the existing daily_summary report

Finishing

Review everything we built. Any edge cases or error handling missing?

Exploring Unfamiliar Code

Before making any changes, explain how [module/feature] works. Trace
the flow from [entry point] through all the layers. Don't change any
code yet.

Look at @src/services/auth/ and summarize how authentication works.
Include the token lifecycle, middleware chain, and error handling paths.

What test files exist for the billing module? What scenarios do they
cover? What is missing?

Git Integration

Commit Messages

Commit these changes with an appropriate message

Commit with a conventional commit message that explains what and why.

Understanding History

What changed in the last 5 commits?

Explain commit abc1234 and its impact

Who last modified line 42 of auth.ts and why?

Reviewing Before Push

Review all uncommitted changes for issues before I push

Comparing Branches

What are the differences between main and feature/oauth?

Creating a PR

Create a GitHub PR. Generate a description from the diff that explains
what changed, why, how to test, and any decisions reviewers should know.

Extended Thinking

Use these patterns when Claude needs to reason through complex problems.

Plan Mode

See the full Plan Mode guide for details.

Git Worktrees

Use worktrees for parallel Claude Code sessions on the same repository. See the full Worktrees guide.

Subagents

Claude can fork independent investigation threads that run in parallel. See the full Subagents guide.

Launch subagents to investigate these three areas in parallel:
 1. How the auth service handles token refresh
 2. What database migrations ran in the last month
 3. Which API endpoints lack input validation

MCP Server Management

See the full MCP Servers guide for details.

Common Servers

# SQLite database access
claude mcp add my-db -- npx -y @anthropic/mcp-server-sqlite --db ./data.db

# Filesystem read/write
claude mcp add files -- npx -y @anthropic/mcp-server-filesystem /path/to/dir

# GitHub API integration
claude mcp add github -- npx -y @anthropic/mcp-server-github

# PostgreSQL database access
claude mcp add pg -- npx -y @anthropic/mcp-server-postgres "postgresql://user:pass@localhost/db"

Workflow Patterns

TDD Loop

1. "Write a failing test for [behavior]"
2. Run test — verify it fails
3. "Write minimum code to pass this test"
4. Run test — verify it passes
5. After 3-5 tests: "Refactor, keep tests green"
6. Repeat

Bug Fix Loop

1. "Write a test that reproduces [bug]"
2. Run — confirm it fails
3. "Fix the bug"
4. Run — confirm it passes
5. Run all tests — nothing else broke

Review Loop

1. Stage changes (git add)
2. "Review staged changes for [focus area]"
3. Fix issues Claude finds
4. /diff to verify fixes
5. Commit

Feature Building Loop

1. "Read [files]. Describe approach for [feature]."
2. Review plan — adjust
3. "Build [piece 1]" — test — /diff — commit
4. "Build [piece 2]" — test — /diff — commit
5. "Review everything. Missing edge cases?"

Explore-Plan-Code-Commit

1. Explore: "Summarize how [module] works. Show dependencies and tests."
2. Plan: "Propose three approaches to [goal] with tradeoffs."
3. Code: "Implement Option B. Start with data model changes only."
4. Commit: "Commit with a conventional commit message referencing the ADR."

Configuration

.claude/settings.json — Pre-approve Commands

{
  "permissions": {
    "allow": [
      "Bash(./gradlew test*)",
      "Bash(npm test*)",
      "Bash(bundle exec rspec*)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git status*)"
    ]
  }
}

CLAUDE.md — Project Instructions

Put in your project root. Claude reads it automatically:

## Testing
- Use JUnit 5 with AssertJ assertions
- Test naming: methodName_givenCondition_expectedResult
- 80% coverage target on new code

## Code Style
- Java: follow Google Java Style Guide
- TypeScript: use strict mode, no any types
- Ruby: follow RuboCop defaults

CLAUDE.local.md — Personal Preferences (git-ignored)

- I prefer verbose test names with @DisplayName
- Always include null input edge cases
- I use IntelliJ — suggest keyboard shortcuts for that IDE

Working with CLAUDE.md

Your CLAUDE.md eliminates repetitive prompting. Add constraints once instead of every time:

Team Setup Checklist

Use this when expanding Claude Code adoption across your organization.

Phase 1: Prerequisites

• API access confirmed: Ensure your Anthropic API key or enterprise agreement supports the number of developers who will use Claude Code
• License allocation: Confirm each developer has an active license or API key with sufficient quota
• Security review: Have your security team review data handling, permission model, and network access
• Policy decisions: Decide which repositories may use Claude Code, file exclusions, MCP approval process, and CLAUDE.md ownership

Phase 2: Configuration

• Create the team CLAUDE.md: Define coding standards, testing conventions, and project-specific instructions
• Set up .claude/settings.json: Define team-wide permission rules (start restrictive, loosen over time)
• Create .claude/settings.local.json template: Provide a starter template for personal settings
• Add to .gitignore: Ensure CLAUDE.local.md and .claude/settings.local.json are git-ignored
• Set up custom commands: Create team slash commands in .claude/skills/
• Configure hooks: Set up pre-commit linting and post-save formatting in shared settings

Phase 3: Managed Settings (Enterprise)

• Configure managed permissions: Set org-wide allow/deny rules that individual developers cannot override
• Set managed MCP servers: Pre-configure approved MCP server connections
• Manage environment variables: Use your secrets manager to distribute API keys securely
• Audit logging: Enable audit logging to track usage patterns

Phase 4: Onboarding New Users

• Installation guide: Write a step-by-step guide covering Node.js prerequisites, npm install, and authentication
• First-day exercise: Provide a “hello world” exercise covering the most common workflow
• Pair programming session: Have each new user pair with a trained engineer for their first real task
• Share the CLAUDE.md: Walk new users through the team’s conventions
• Point to resources: Share continued learning links to Skilljar courses and documentation

Phase 5: Ongoing Maintenance

• CLAUDE.md updates: Assign ownership; treat updates like code changes with PR reviews
• Permission rule audits: Review allow/deny lists quarterly
• Command library growth: Encourage engineers to create and share new slash commands
• Metrics review: Track time-to-PR, review cycles, test coverage, and developer satisfaction

Common Pitfalls

1. Starting too permissive: Begin with restrictive permissions and loosen over time
2. Skipping CLAUDE.md: Without one, each developer gets inconsistent results
3. No measurement: Without baseline metrics, you cannot demonstrate ROI
4. Forcing adoption: Mandate the setup, but let usage grow organically
5. Ignoring security review: Get security buy-in early to avoid retroactive restrictions

The Prompting Hierarchy

From most to least effective:

1. Context + Constraints + Example — Show what to reference, what to avoid, and what the output should look like
2. Context + Constraints — Reference existing code, list what NOT to do
3. Context only — Point to files to reference
4. No context — Generic results, heavy editing needed

The golden rule: Be specific about what you want, and explicit about what you don’t want.

Pro Tips

• Use /clear between tasks — prevents context bleed between reviews
• Use /compact when context is heavy — keeps the session going without losing key info
• /cost to track spend — check token usage before and after expensive operations
• /context to visualize usage — see how full your context window is
• Be specific — “check for SQL injection” beats “review this code”
• Give context — “this handles payments” changes what Claude flags
• Push back — Claude over-implements sometimes. Say “just do X, not Y”
• Review /diff — always check what Claude actually changed
• One thing at a time — small focused prompts beat big vague ones
• Stage before review — git add -p then “review staged changes”
• Batch mode for CI — claude -p "review src/file.ts" > report.md
• Use ! for quick shell commands — ! git status runs inline without leaving Claude
• /btw for side questions — ask without polluting conversation context