Master Claude Code: From ‘It Works’ to ‘It Actually Works Well’ – The Complete Guide

高效码农

4 hours ago

Claude Code Best Practices: From “It Works” to “It Actually Works Well”

Core question this article answers: Why do some developers find Claude Code underwhelming while others double their productivity with it? The difference lies in how you use it—this guide covers the complete methodology from basic configuration to advanced workflows.

I’ve been using Claude Code for over half a year. I’ve made more mistakes than I’ve written lines of code. At first, I thought Claude Code was just “a more advanced Copilot”—type in the terminal, it writes code for me, done. Later, I discovered that its ceiling is far higher than I imagined, but only if you know how to use it.

This article combines official documentation with practical experience, organizing what I consider the most important usage techniques. Some are lessons learned the hard way; others are hidden features I only discovered by reading the docs.

1. CLAUDE.md: The Most Underrated Feature

Core question: How do you ensure Claude Code understands your project context and personal preferences accurately in every conversation without repeated explanations?

If you remember only one thing from this article, remember this: write your CLAUDE.md well.

CLAUDE.md is an instruction file that Claude Code automatically reads at the start of every conversation. It’s like an onboarding document you write for a new colleague—whatever you want them to know, you put here.

Many people don’t write CLAUDE.md, or they write just two casual lines. The result: every conversation starts from scratch explaining project structure, coding standards, and technology choices. It’s like reintroducing your company to a colleague every morning.

What Should a Good CLAUDE.md Include?

# Project Name

## Build and Test Commands
- Install dependencies: npm install
- Run tests: npm test
- Single test: npm test -- --grep "test name"
- Formatting: npm run format

## Coding Standards
- Python uses ruff formatter, line width 88
- Testing with pytest, one test file per service
- API route files use plural names: users.py, orders.py
- Commit messages in English, format: type(scope): description

## Architecture Decisions
- Chose Tailwind over CSS Modules because the team standardized on it
- User permission checks go in middleware, don't repeat in every route
- Redis cache key prefix统一用 `app:v1:`

## Common Pitfalls
- Database connection pool limit is 20, don't open new connections in loops
- Don't mock the database; last time mock tests passed but production migration failed

Key principles to follow:

First, write what Claude can’t read from the code. The “why” of a project matters more than the “what.” You don’t need to explain how React works, but you do need to tell it “we chose Tailwind because the team standardized on this specification.”

Second, keep it under 200 lines. The official documentation explicitly mentions that CLAUDE.md that’s too long causes Claude to ignore rules. Use markdown headers and lists to maintain scannability.

Third, don’t put frequently changing content. Detailed API documentation, file-by-file descriptions—these don’t belong in CLAUDE.md. Put links instead.

The Four-Level Hierarchy of CLAUDE.md

Claude Code supports four levels of CLAUDE.md, prioritized from highest to lowest:

Level	Location	Use Case
Organization Policy	`/Library/Application Support/ClaudeCode/CLAUDE.md` (macOS)	IT admin unified policies
Project Root	`./CLAUDE.md` or `./.claude/CLAUDE.md`	Project-level standards, committed to Git
User Global	`~/.claude/CLAUDE.md`	Personal preferences, applies to all projects
Subdirectory	`./src/CLAUDE.md`	Module-specific conventions, lazy-loaded as needed

My global CLAUDE.md typically contains:

- I'm a full-stack engineer, no need to over-explain basic concepts
- Keep responses concise, no unnecessary pleasantries
- Don't summarize what you did after code changes, I'll read the diff
- Prefer simple solutions, don't over-engineer

These four lines save you hundreds of repetitive corrections.

Advanced: Organizing Rules with .claude/rules/

When projects grow large, one CLAUDE.md file can’t hold all rules. The official docs provide an elegant solution: split rules into the .claude/rules/ directory.

.claude/rules/
├── testing.md        # Testing standards
├── api-style.md      # API writing style
└── frontend.md       # Frontend conventions

More powerfully, you can use YAML frontmatter to scope rules to specific files:

---
paths: ["src/api/**/*.ts", "src/routes/**/*.ts"]
---

API routes must include input validation and error handling.
All new endpoints need integration tests under tests/api/.

This way, the rule only loads when Claude accesses matching files, saving context space.

2. Prompt Quality Determines Output Quality

Core question: Why does Claude Code sometimes generate completely off-target code, while other times it’s remarkably precise?

This sounds obvious, but I’ve seen too many people use Claude Code like this:

“Help me write a login feature”

Then they stare at the massive chunk of generated code in frustration—that’s not what I wanted!

Good instructions should contain three elements: goal, constraints, and context.

Bad vs. Good Instructions

Bad: “Add a search feature to the user list”

Good: “Add a search box above the table in /UserList.tsx. Search should hit the backend API /api/users?search=xxx, not frontend filtering. Use 300ms debounce, style consistent with the existing Filter component.”

What’s the difference? Good instructions reduce ambiguity. Claude Code doesn’t need to guess whether you want frontend or backend search, doesn’t need to guess debounce timing, doesn’t need to guess style standards.

Official Recommended Prompting Techniques

1. Use @ to Reference Specific Files

Claude Code supports using @file-path to pull file content directly into context. Instead of saying “that authentication-related code,” directly writing @/login.ts is much more precise. You can even specify line ranges: @/login.ts#5-30.

2. Paste Screenshots and Images

Use Ctrl+V to paste images directly. When debugging UI issues, pasting a screenshot of “how it looks now” versus “how I want it” is ten times more effective than text descriptions.

3. Provide Validation Criteria

Don’t just say “help me fix this bug.” Instead:

“Fix the issue where login timeout prevents re-authentication. After fixing, when the token expires, clicking any button should automatically redirect to the login page. Test cases are in auth.test.ts, run them after fixing to confirm they pass.”

Give Claude a self-validation standard—test cases, screenshots, expected output—and it can check its own work quality, reducing back-and-forth revisions.

4. Explicitly State What NOT to Do

Claude Code can sometimes be overly enthusiastic—you ask it to fix a bug, and it casually refactors surrounding code too. Explicitly saying “only change this function, don’t touch other code” saves a lot of trouble.

Fuzzy Instructions Have Their Place Too

Not all situations require precise instructions. Exploratory tasks actually benefit from fuzzy instructions:

“What could be improved in this file?”
“Help me understand this module’s architecture”
“What potential issues does this code have?”

But when you reach implementation phase, switch to precise mode.

3. Plan Mode: Think First, Act Later

Core question: When facing complex tasks, how do you prevent Claude Code from blindly modifying code and making things worse?

Claude Code has a Plan Mode, which I consider the most underrated workflow.

How to Enter Plan Mode

Three ways:

# Launch directly into plan mode
claude --permission-mode plan

# Switch during conversation (press Shift+Tab twice)
Shift+Tab Shift+Tab

# Or say it in the prompt
"Don't change code yet, help me make a plan first"

In Plan Mode, Claude Code can only read files and search code—it can’t make any modifications. It explores the codebase, analyzes your requirements, then provides a detailed implementation plan.

The Correct Way to Use Plan Mode

Key operation: Press Ctrl+G to open and edit the plan in your editor.

This means you can:

Have Claude generate an initial plan
Open the plan with Ctrl+G, delete parts you disagree with, add your own thoughts
Switch back to normal mode (Shift+Tab), and have Claude execute the modified plan

Changing a plan takes one sentence; changing already-written code takes ten times the effort.

Recommended Complex Task Workflow

The official recommended standard process is four steps: Explore → Plan → Implement → Validate.

1. Enter Plan Mode
2. Have Claude read relevant code: "Read the code under src/auth/, understand session handling logic"
3. Request a plan: "Develop an OAuth2 migration strategy"
4. Review and edit the plan with Ctrl+G
5. Switch back to normal mode
6. "Implement according to the plan, run tests when done"
7. Have Claude self-check against requirements

When You Don’t Need Plan Mode

Renaming a variable
Fixing an obvious typo
Adding a log line

The judgment standard is simple: if there’s only one way to implement this task, just do it. If there are multiple choices, plan first.

4. Sub-Agents: Claude Code’s Cloning Technique

Core question: How do you perform time-consuming operations (like running tests, searching large files) without polluting your main conversation context?

Sub-agents are a powerful mechanism in Claude Code—it can launch independent AI processes to handle tasks in parallel, each sub-agent with its own context window that won’t pollute your main conversation.

Built-in Sub-Agent Types

Type	Capability	Use Case
Explore	Read-only, fast codebase search	Exploration, finding files, finding definitions
Plan	Read-only, research and analysis	Code analysis in Plan Mode
General	Full capabilities	Complex multi-step tasks

Sub-Agents’ Greatest Value: Context Isolation

When you have Claude run tests, analyze logs, or search large files, these operations generate massive output that fills your context window. Using sub-agents for these tasks keeps the output in the sub-agent’s context, with only summaries returning to you.

For example:

“Use a sub-agent to run the full test suite, list the failed cases”

“Use a sub-agent to search all files using deprecated APIs”

Background Execution: Ctrl+B

Press Ctrl+B to run a sub-agent in the background. You can continue talking to Claude about other things, and you’ll be notified when the background task completes.

Good for:

Running test suites (usually takes several minutes)
Large-scale code searches
Non-urgent code reviews

Custom Sub-Agents

You can create custom agents in the .claude/agents/ directory:

---
name: code-reviewer
description: Code review expert. Auto-triggered after code changes.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You are a senior code reviewer. Check these dimensions:
- Code clarity and readability
- Whether error handling is complete
- Any exposed sensitive information
- Input validation
- Performance risks

Then invoke it in conversation with @"code-reviewer (agent)".

5. Context Management: The Most Overlooked Key

Core question: Why does Claude Code’s response quality seem to decline as conversations get longer?

Claude Code’s context window is large (up to 1M tokens), but it’s not unlimited, and context management directly determines output quality.

What’s in the Context?

Your conversation history
All file content Claude has read
Command execution output
CLAUDE.md files (loaded every time)
Memory files (first 200 lines)
Loaded Skills and MCP tool definitions

Five Practical Strategies

1. /clear: One Task, One Conversation, Then Clear

Don’t fix bugs, add features, and refactor all in one conversation. /clear empties context but keeps CLAUDE.md, essentially a free restart.

2. /compact: Manually Compress Context

When conversations get long, type /compact to have Claude automatically summarize and compress previous conversation. Better yet, add a focus to the compression:

/compact focus on API changes and test results

This way Claude prioritizes keeping content you care about when compressing.

3. /context: See What’s Eating Your Context

Type /context to see current context usage—which files are taking how many tokens, how much MCP tool definitions are using. I often find unused MCP servers taking up massive space.

4. Use Sub-Agents to Isolate Noise

Running tests, analyzing logs—these operations generate large output. Have sub-agents do them, keep the main conversation context clean.

5. Write Compression Retention Instructions in CLAUDE.md

You can tell Claude what to always keep when compressing:

# Compression Instructions
When compressing context, always retain:
- Complete list of modified files
- Test commands and results
- Key architecture decisions

Memory vs CLAUDE.md

Dimension	CLAUDE.md	Memory
Who Writes	You	Claude
Content	Instructions and rules	Learned patterns and preferences
Loading	Full load, every conversation	First 200 lines + on-demand loading
Purpose	Guide behavior	Accumulate knowledge

What Memory is good for: Your preferences (“this person likes concise responses”), project conventions (“deployment has a special step”), historical decisions (“chose option A last time because of X”).

What Memory is NOT good for: Code details, Git history, temporary states—these are more accurately obtained from code and Git.

Use the /memory command to view and manage all loaded Memory.

6. Permission Management: Balancing Security and Efficiency

Core question: How do you reduce the friction of Claude Code asking for approval on every operation while maintaining security?

Claude Code provides five permission modes, cycled with Shift+Tab during conversation:

Mode	Behavior
`default`	Ask on first use of each tool type
`acceptEdits`	Auto-accept file edits, still ask for commands
`plan`	Read-only analysis, no modifications
`dontAsk`	Auto-reject unless pre-approved
`bypassPermissions`	Skip all asking. Use with caution!

Permission Rule Configuration

In .claude/settings.json, you can finely control permissions for each tool:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Edit(src/**/*.ts)",
      "Read(*.md)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Edit(.env)"
    ]
  }
}

Rule priority: deny → ask → allow (deny takes highest precedence).

This means you can boldly allow common commands while using deny to protect sensitive files. For example, .env files should never be edited regardless of circumstances.

Settings File Hierarchy

Like CLAUDE.md, settings also have multiple levels:

Organization Policy (highest priority)
  ↓
CLI arguments
  ↓
.claude/settings.local.json (local, not committed to Git)
  ↓
.claude/settings.json (project-level, team-shared)
  ↓
~/.claude/settings.json (global, personal)
  ↓
Defaults (lowest priority)

My recommendation: Put team-shared rules in .claude/settings.json, personal preferences in ~/.claude/settings.json, and sensitive configs in .claude/settings.local.json (remember to add to .gitignore).

7. Hooks: Turning Rules into Iron Laws

Core question: How do you ensure certain critical rules (like code formatting, sensitive file protection) are never ignored?

Instructions in CLAUDE.md are “suggestions”—Claude follows them most of the time but occasionally forgets. Hooks are “iron laws”—they execute regardless.

Hooks are shell commands automatically triggered at specific lifecycle events. Configured in settings.json.

Key Event Types

Event	Trigger Timing	Typical Use
`PreToolUse`	Before tool execution	Intercept dangerous operations
`PostToolUse`	After tool execution	Auto-formatting, running lint
`Notification`	When Claude sends notifications	Desktop alerts
`Stop`	When Claude finishes responding	Post-processing

Practical Examples

Auto-formatting—run Prettier after every edit:

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

Protect critical files—block modifications to production configs:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": ".claude/hooks/protect-files.sh"
      }]
    }]
  }
}

Hook commands return exit code 0 to allow, exit code 2 to block. This means you can write arbitrarily complex judgment logic.

Re-inject critical info after context compression:

{
  "hooks": {
    "SessionStart": [{
      "matcher": "compact",
      "hooks": [{
        "type": "command",
        "command": "echo 'Use Bun not npm. Run bun test before committing.'"
      }]
    }]
  }
}

This solves a common pain point: when conversations get long and compressed, previously mentioned important instructions might be lost. Hooks can automatically re-inject them after each compression.

Four Types of Hooks

Type	Description
command	Execute shell command, read JSON from stdin
http	Send POST request to URL
prompt	Single LLM call, yes/no judgment
agent	Launch sub-agent for validation

8. Git Workflow: Making Good Use of Worktree

Core question: How do you let Claude Code explore freely while ensuring it doesn’t mess up your main branch code?

Claude Code can execute Git commands, which is a double-edged sword. But the official docs provide a good safety net: Worktree.

Git Worktree: Isolated Workspace

# Launch Claude in isolated worktree
claude --worktree feature-auth
claude --worktree bugfix-123

# Auto-generate name
claude --worktree

Worktree creates an independent Git branch copy under .claude/worktrees/. Whatever Claude does inside doesn’t affect your main branch. On exit:

If no changes → auto-cleanup
If changes → prompt to keep or discard

This is especially useful for exploratory tasks. Not sure if a refactoring approach will work? Open a worktree to try it, throw it away if it doesn’t, zero risk.

Several Git Iron Laws

1. Never let Claude Code auto-push

It can commit, but the push action should be confirmed by you. Once pushed to remote, rollback costs increase.

2. Commit frequently

Commit after each small feature. Use /rewind to rollback to any checkpoint, but only if you have commit records.

3. Be wary of destructive operations

If Claude Code wants to execute git reset --hard, git push --force, rm -rf, always think through the consequences before approving. These operations have no undo. You can also directly deny these commands in permission rules.

4. Restore context from PR

claude --from-pr 123

This automatically loads the PR’s changes and discussion as context, perfect for code review or continuing someone else’s work.

9. Shortcuts and Command Quick Reference

Core question: Which high-frequency operations can significantly improve efficiency through keyboard shortcuts?

I use these shortcuts daily; highly recommended to memorize them:

Most Frequently Used Shortcuts

Operation	Shortcut	Description
Switch permission mode	`Shift+Tab`	Cycle through default/acceptEdits/plan
Undo/rollback	`Esc, Esc`	Return to previous checkpoint
Edit in editor	`Ctrl+G`	Edit current input or plan with $EDITOR
Background execution	`Ctrl+B`	Run sub-agent in background
Paste image	`Ctrl+V`	Paste screenshot directly into conversation
Switch model	`Cmd+P` / `Ctrl+P`	Select different model
View internal reasoning	`Ctrl+O`	Show Claude’s thinking process
History search	`Ctrl+R`	Search previous conversations
Interrupt	`Ctrl+C`	Stop Claude’s current operation

Most Frequently Used Slash Commands

/compact [focus]     # Compress context, can specify retention focus
/clear              # Clear conversation, start fresh
/context            # View context usage
/memory             # View and manage Memory
/rewind             # Rollback to a checkpoint
/resume [name]       # Resume previous conversation
/model              # Switch model
/effort [level]      # Set reasoning depth: low/medium/high/max
/init               # Auto-generate CLAUDE.md
/mcp                # Manage MCP servers
/permissions        # View permission rules
/cost               # View token consumption

/init is especially useful for new projects—it automatically analyzes your codebase and generates a CLAUDE.md draft. Usually needs manual adjustment, but much faster than starting from scratch.

10. Extended Thinking: Making Claude Think Deeper

Core question: When facing complex decisions, how do you get Claude Code to perform deeper reasoning rather than surface analysis?

For complex problems, you can enable Extended Thinking mode, letting Claude spend more time reasoning before responding.

How to Use

# Shortcut toggle
Option+T (Mac) / Alt+T (Windows/Linux)

# Or use command
/effort high    # Deeper reasoning
/effort max     # Maximum reasoning depth
/effort low     # Simple tasks, save tokens

When to Use

Complex architecture decisions
Tricky debugging (multiple possible causes to eliminate)
Multi-step refactoring plan design
Weighing pros and cons of multiple approaches

When Not Needed

Simple code modifications
Formatting, renaming
Already clear bug fixes

Pro tip: Writing ultrathink in the prompt can force-trigger maximum reasoning depth without manually adjusting effort settings.

11. MCP Server: Connecting Claude to the External World

Core question: How do you enable Claude Code to seamlessly collaborate with external tools like GitHub, databases, and Slack?

MCP (Model Context Protocol) lets Claude Code communicate with external tools—GitHub, databases, Slack, Notion, and more.

Quick Add

claude mcp add github -- npx @anthropic-ai/mcp-server-github
claude mcp add postgres -- npx @anthropic-ai/mcp-server-postgres postgresql://localhost:5432/mydb

Configuration File

MCP config goes in .mcp.json:

{
  "mcpServers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "$GITHUB_TOKEN"
      }
    }
  }
}

Watch Out for Context Overhead

Each MCP server consumes an additional 100-500+ tokens for tool definitions. Use /mcp to view each server’s overhead, disable unused ones.

My experience: don’t be greedy. 2-3 commonly used MCP servers are enough. Install too many, and context space gets eaten by tool definitions, negatively impacting code analysis quality.

12. IDE Integration: More Than Just Terminal

Core question: How do you use Claude Code in your familiar IDE environment without constantly switching windows?

VS Code

After installing the Claude Code extension, you can use Claude directly in VS Code without switching to the terminal.

Several useful features:

Side-by-side diff view: Claude’s changes shown as diffs, clear at a glance
Option+K / Alt+K: Quick insert of current file @reference
Multi-tab conversations: Multiple independent conversations in different tabs
Cmd+Shift+Esc: Quickly open new conversation tab

JetBrains

IntelliJ, PyCharm, WebStorm, and the entire JetBrains family have Claude Code plugins too. Search “Claude Code” in the Plugins marketplace to install.

13. Code Review: Trust but Verify

Core question: What’s the quality of code written by Claude Code? What common pitfalls should you watch for?

Claude Code’s code quality is generally good, but you can’t blindly trust it.

Several Common Issues

1. Over-engineering

You ask for a simple utility function, it gives you a complete abstraction layer with generics, interfaces, and factory patterns. Using a sledgehammer to crack a nut.

Solution: Write “prefer simple solutions” in CLAUDE.md, or explicitly say “no abstraction needed” in instructions.

2. Hallucinated APIs

Sometimes it uses non-existent APIs or outdated syntax. Especially for niche libraries’ new versions.

Solution: Run tests. This is why instructions should include validation criteria.

3. Scope Creep

You ask it to change one function, it refactors the entire file.

Solution: Explicitly say “only change X, don’t touch other code.” Or use /freeze command to limit edit scope to specific directories.

Writer/Reviewer Mode

An official recommended advanced pattern: use two independent sessions as “code writer” and “code reviewer.”

The two sessions have independent contexts; the Reviewer isn’t influenced by the Writer’s thought process, and can spot the Writer’s blind spots.

Session A (Writer): "Implement API rate limiting middleware"
Session B (Reviewer): "Review the rate limiting implementation in @src/middleware/rateLimiter.ts,
                      focus on edge cases, race conditions, consistency"
Session A: "Fix review feedback: [paste B's output]"

14. What NOT to Do with Claude Code

Core question: Which scenarios or usage patterns turn Claude Code from an assistant into a risk source?

Having covered “what you should do,” let’s talk about “what you shouldn’t do.”

1. Don’t let it do things you completely don’t understand

If you know nothing about Kubernetes, don’t have Claude Code write deployment configs for you and use them directly. You can’t review what you don’t understand.

2. Don’t use it without version control

No Git means no rollback capability. Claude Code’s changes might overwrite your files; without version control, you’re running naked.

3. Don’t throw one massive task at it

“Migrate the entire project from JavaScript to TypeScript”

This kind of instruction lets Claude Code run wild. Results are uncontrollable. Break into small steps, confirm each step before moving to the next.

4. Don’t expect perfection on the first try

Iteration is normal. Use /rewind to rollback, use precise feedback describing “what’s wrong.”

Reflections and Lessons: My Personal Takeaways

After using Claude Code for over half a year, here are some hard-won lessons:

About CLAUDE.md: I spent two weeks repeatedly correcting Claude’s response style before realizing I just needed to add four lines to my global CLAUDE.md. Those two weeks of repetitive labor could have been solved with five minutes of configuration.

About Plan Mode: I once had Claude directly modify a core module; it changed 20 files and introduced two bugs. After rolling back, I used Plan Mode to redo it, and found I only needed to change 3 files. Planning before acting saves not just time, but also the trouble of rolling back.

About Context Management: There were times late in conversations when Claude started “forgetting”—rules mentioned earlier were forgotten again. Later I learned to use /compact with focus, and to /clear promptly, and such problems never occurred again.

About Permissions: I once accidentally had Claude execute an rm -rf, fortunately in a worktree. Since then, my settings.json always has "deny": ["Bash(rm -rf *)"].

The common thread in these lessons: Claude Code is an extremely powerful tool, but a tool’s power doesn’t mean you can stop thinking. The steering wheel is always in your hands.

Practical Summary: Action Checklist

First-time Claude Code setup:

Run claude /init to generate initial CLAUDE.md
Edit ~/.claude/CLAUDE.md to write personal preferences
Create .claude/CLAUDE.md in project root for project standards
Configure .claude/settings.json to set permission rules
Add necessary MCP servers (claude mcp add)

Best practices for every conversation:

One task per conversation, use /clear when done
For complex tasks, enter Plan Mode first (Shift+Tab twice)
Use @file-path for precise context references
Provide clear validation criteria (test cases, expected behavior)
Commit frequently, preserve /rewind capability

Troubleshooting steps when issues arise:

Context too full? Use /compact or /clear
Claude ignoring rules? Check if CLAUDE.md exceeds 200 lines
Too many permission prompts? Adjust allow/deny rules in settings.json
Inconsistent code quality? Enable Writer/Reviewer dual-session mode

One-Page Overview

Feature	Core Usage	Shortcut/Command
CLAUDE.md	Project standards and personal preferences	`~/.claude/CLAUDE.md`, `./CLAUDE.md`
Plan Mode	Plan complex tasks first	`Shift+Tab` ×2, `Ctrl+G` to edit
Sub-Agents	Isolate time-consuming operations	`Ctrl+B` for background execution
Context Management	Keep conversations clear	`/clear`, `/compact`, `/context`
Permission Control	Balance security and efficiency	`Shift+Tab` to cycle, `settings.json`
Hooks	Automate rule enforcement	Configure in `settings.json`
Worktree	Isolate experimental changes	`claude --worktree`
Extended Thinking	Deep reasoning	`Option+T` / `Alt+T`, `/effort`

Frequently Asked Questions (FAQ)

Q1: What’s the difference between CLAUDE.md and Memory, and which should I write to?

CLAUDE.md is an instruction file you write, fully loaded every conversation, suitable for explicit rules and project info. Memory is preferences and patterns Claude automatically accumulates, suitable for letting it learn your habits. Write hard project rules in CLAUDE.md; let Claude learn soft personal habits in Memory.

Q2: Why does Claude sometimes ignore rules clearly written in CLAUDE.md?

Most likely cause: CLAUDE.md is too long. Official docs explicitly state that exceeding 200 lines causes rules to be ignored. Check your file length; split infrequently used content into .claude/rules/ directory, using path scoping for on-demand loading.

Q3: What’s the real difference between Plan Mode and normal mode?

In Plan Mode, Claude can only read, not write—it explores the codebase first, then provides an implementation plan. Suitable for complex tasks with multiple implementation choices. If you’re sure “this bug only needs this one line changed,” use normal mode. If you’re thinking “how should I implement this requirement,” enter Plan Mode first.

Q4: What’s the difference between sub-agents and main conversation? When should I use them?

Sub-agents have independent context windows. Operations that generate massive output like running tests or searching large files—using sub-agents prevents polluting the main conversation. Press Ctrl+B to run in background without blocking your continued conversation.

Q5: How do I prevent Claude from modifying files I don’t want touched?

Add rules to .claude/settings.json‘s permissions.deny, like "Edit(.env)". Or use Hooks in PreToolUse events to write scripts that intercept. Safest is using Git Worktree (claude --worktree) to isolate operations.

Q6: What’s the difference between /compact and /clear, and when to use which?

/compact summarizes and compresses context, keeping key information—suitable for when conversations get long but you want to continue the current task. /clear completely empties for a fresh start—suitable when one task is done and you’re switching to another. If Claude still “forgets” after compression, use /clear.

Q7: What are the side effects of installing too many MCP Servers?

Each MCP server consumes 100-500+ tokens of context space. Installing too many reduces space available for code analysis, impacting quality. Recommended: only install the 2-3 most commonly used, view overhead with /mcp, disable unused ones promptly.

Q8: Why does Claude sometimes generate code using non-existent APIs?

This is “hallucination,” especially common with niche libraries or new versions. Solution: provide validation criteria in instructions (“run tests to confirm they pass”), and specify exact dependency versions in CLAUDE.md.

Q9: How exactly does Writer/Reviewer mode work?

Open two independent Claude Code sessions (can use VS Code’s multi-tab). Session A writes code, Session B reviews. B isn’t influenced by A’s thought process, and can spot A’s blind spots. A modifies based on B’s feedback, iterating until B approves.

Q10: What should I prioritize configuring when first starting with Claude Code?

By priority: 1) Write global CLAUDE.md defining personal preferences; 2) Write project CLAUDE.md defining technical standards; 3) Configure permission rules to protect sensitive files; 4) Learn to use Plan Mode for complex tasks; 5) Develop the habit of frequent commits. Doing these five things elevates the experience significantly.