Claude Code Best Practices: 10 Habits From Anthropic's Docs

Almost every Claude Code best practice comes back to one constraint: the context window fills up fast, and Claude gets worse as it fills. Every message, every file Claude reads, and every command output lands in that window. Once it's crowded, Claude starts forgetting earlier instructions and making more mistakes.

Anthropic's own best practices guide is built around that idea. Here are the habits that matter most, in the order you'll use them:

1. Give Claude a check it can run
2. Explore, then plan, then code
3. Write specific prompts with real context
4. Keep CLAUDE.md short
5. Cut permission prompts without giving up control
6. Course-correct early, and rewind freely
7. Clear and compact context on purpose
8. Push research into subagents
9. Resume sessions instead of re-explaining
10. Scale out with non-interactive mode and parallel sessions

If you're asking how to use Claude Code well, or looking for a Claude Code tutorial that goes past installation, this is that list with the exact commands. Every command and shortcut below is one Anthropic documents.

Give Claude a check it can run

Claude stops when the work looks done. Without a check, "looks done" is the only signal, and you become the verification loop.

The fix is something that returns pass or fail: a test suite, a build exit code, a linter, a script that diffs output against a fixture, or a screenshot compared against a design. Then Claude does the work, runs the check, reads the result, and iterates.

The docs describe four levels of how hard the check gates the stop:

• In one prompt: ask Claude to run the check and iterate, like the table above.
• Across a session: set the check as a /goal condition. A separate evaluator re-checks it after every turn.
• As a deterministic gate: a Stop hook runs your check as a script and blocks the turn from ending until it passes.
• By a second opinion: a verification subagent tries to refute the result, so the agent that did the work isn't grading itself.

Whichever you pick, ask Claude to show evidence: the test output, the command it ran, a screenshot. Reading evidence is faster than re-running everything yourself.

Explore, then plan, then code

Letting Claude jump straight into code can solve the wrong problem. Anthropic recommends four phases:

1. Explore. Press Shift+Tab until the status bar shows plan mode, or start with claude --permission-mode plan. Claude reads files and answers questions without changing anything.
2. Plan. Ask for a detailed implementation plan. Press Ctrl+G to open the plan in your text editor and edit it before Claude proceeds.
3. Implement. Approve the plan or press Shift+Tab to leave plan mode, then let Claude code and test against the plan.
4. Commit. Ask Claude to commit with a descriptive message and open a PR.

Plan mode adds overhead, so don't use it for everything. The docs' rule of thumb: if you could describe the diff in one sentence, skip the plan. Planning pays off when you're unsure of the approach, the change touches several files, or you don't know the code.

Write specific prompts with real context

Claude can infer intent, but it can't read your mind. Four moves cut down on corrections:

• Scope the task. "write a test for foo.py covering the edge case where the user is logged out. avoid mocks" beats "add tests for foo.py."
• Point to sources. "look through ExecutionFactory's git history and summarize how its api came to be" sends Claude to the answer.
• Reference existing patterns. Name a file in your codebase that already does it right, and tell Claude to follow it.
• Describe the symptom. Give the symptom, the likely location, and what "fixed" looks like.

Feed it rich context, too. Use @ to reference a file instead of describing where code lives. Paste or drag in screenshots. Give documentation URLs. Pipe data in directly: cat error.log | claude -p "explain this error".

For bigger features, flip it around. Ask Claude to interview you with the AskUserQuestion tool about implementation, UI, edge cases, and tradeoffs, then write a spec to SPEC.md. Start a fresh session to implement it, so the new session has clean context and a written spec.

Keep CLAUDE.md short, and let hooks and skills carry the rest

CLAUDE.md is the file Claude reads at the start of every conversation. Run /init to generate a starter one from your project, then run /context to confirm it loaded.

The test for every line, straight from Anthropic: would removing this cause Claude to make mistakes? If not, cut it. A bloated CLAUDE.md makes Claude ignore the rules you actually care about.

If Claude keeps skipping one instruction, add "IMPORTANT" to that line only. Emphasize everything and nothing stands out. For a checked-in CLAUDE.md, /doctor proposes cuts for content Claude can derive from the codebase. Our CLAUDE.md file guide covers where the file lives and how @imports work.

Two rules keep CLAUDE.md lean:

• Must happen every time? Use a hook. CLAUDE.md is advisory; hooks are deterministic. Run /hooks to see what's configured.
• Only relevant sometimes? Use a skill. Skills in .claude/skills/ load on demand instead of in every session, and you can invoke one with /skill-name.

Cut permission prompts without giving up control

In Manual mode, Claude Code asks before file writes, Bash commands, and MCP tools. Safe, but after the tenth approval you're clicking, not reviewing.

Two tools fix that, and both apply in auto mode as well:

• /permissions to allowlist specific commands you trust, like npm run lint or git commit.
• /sandbox to turn on OS-level isolation that restricts filesystem and network access, so sandboxed commands can run without asking.

The docs note that from Claude Code v2.1.283, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions. A separate classifier reviews most actions and blocks what looks risky. Switch to Manual mode when you want to approve everything yourself.

While you're configuring: tell Claude to use CLI tools like gh for external services. The docs call CLI tools the most context-efficient way to reach them.

Course-correct early, and rewind freely

Tight feedback loops beat perfect first prompts. The controls:

Every prompt that starts a turn creates a checkpoint, so you can let Claude try something risky and rewind if it fails. Checkpoints survive closing the terminal. One caveat from Anthropic's checkpointing docs: they only track changes made through Claude's file-editing tools, not Bash commands. They don't replace git.

The two-correction rule. If you've corrected Claude more than twice on the same issue, the context is full of failed attempts. Run /clear and start over with a better prompt that includes what you learned.

Clear and compact context on purpose

Claude Code compacts automatically as you near the limit, but you'll get better results steering it:

• /clear between unrelated tasks. This is the single most repeated tip in the guide.
• /compact with instructions, like /compact Focus on the API changes.
• Partial compaction from the rewind menu: pick a checkpoint and choose Summarize from here or Summarize up to here.
• A line in CLAUDE.md such as "When compacting, always preserve the full list of modified files and any test commands."
• /btw for a side question. The answer never enters conversation history.

Push research into subagents

Research is what fills context fastest, because Claude reads lots of files to answer one question. Say "use subagents to investigate X" and the reading happens in a separate context window. Only a summary comes back. Our Claude Code subagents guide covers how to define your own.

Subagents also make a good final reviewer. Before you call a task done, have one review the diff in a fresh context against your plan. The bundled /code-review skill does a correctness pass. Tell the reviewer to flag only gaps that affect correctness or requirements, or it will invent work to justify itself.

Resume sessions instead of re-explaining

Name sessions with /rename and treat them like branches, one per workstream. Run claude --continue to pick up the last one, or claude --resume to choose from a list.

Scale out with non-interactive mode and parallel sessions

Once one session works well, you can multiply it:

• Non-interactive mode. claude -p "prompt" runs without an interactive prompt, for CI, pre-commit hooks, and scripts. Add --output-format json or --output-format stream-json --verbose for parseable output. The headless mode docs have the details.
• Fan out. /batch with an instruction splits a large change across 5 to 30 subagents, each in its own worktree. Or loop claude -p over a file list with --allowedTools to pre-approve what the job needs. Test on two or three files first.
• Parallel sessions. Worktrees, the desktop app, cloud sessions, agent view (research preview), and agent teams (experimental, off by default) all run several Claudes at once.

One pattern from the docs is worth copying: Writer/Reviewer. Session A implements a feature. Session B, with fresh context, reviews it. Session A addresses the feedback. Claude reviews better when it isn't defending code it just wrote.

The failure patterns to watch for

Anthropic names five:

These best practices complement our Claude Code use cases guide, which covers which tasks Claude Code handles reliably. This list is about how to run it once you've picked one.

If a polished Claude Code setup is exactly what you keep failing to reproduce, Taku mirrors a working AI setup into a desktop workspace and runs it, so you can start from a configuration someone already tuned. Taku is in Beta, and the Mac app is available now.

FAQ

What are the most important Claude Code best practices?

Give Claude a way to verify its work, separate exploring and planning from coding, and manage context aggressively with /clear and /compact. Anthropic's guide treats the context window as the most important resource to manage.

What are some quick Claude Code tips for beginners?

Run /init to create a CLAUDE.md, use plan mode (Shift+Tab) for multi-file changes, reference files with @, press Esc to stop Claude mid-action, and run /clear between unrelated tasks.

How do I use Claude Code for a big feature?

Ask Claude to interview you with the AskUserQuestion tool, have it write a spec to SPEC.md, then start a fresh session to implement against that spec, with tests Claude can run.

How long should CLAUDE.md be?

Short. For each line, ask whether removing it would cause Claude to make mistakes. Move rarely needed knowledge into skills and must-happen rules into hooks.

Can I undo what Claude Code changed?

Yes, for edits made with Claude's file tools. Press Esc twice or run /rewind to restore code, conversation, or both from a checkpoint. Changes made through Bash commands aren't tracked, so keep using git.

Is there an official Claude Code tutorial?

Anthropic's best practices page at code.claude.com is the closest thing to an official Claude Code tutorial for day-to-day habits. The commands in this article all come from it and the linked Claude Code docs.