Claude Code Best Practices: Powerful Habits Guide

Best practices for Claude Code separate developers who ship clean code from those who fight the tool all day. The context window fills up fast, and performance drops as it fills. These best practices help you manage context, verify work automatically, and build habits that make every session more productive.

Best Practices: What You’ll Learn

This guide covers the best practices that Anthropic engineers use daily with Claude Code. You will learn how to manage the context window, set up verification gates, configure your environment, and scale across multiple sessions. These best practices work for solo projects and large teams alike.

Every recommendation here comes from real production usage. The goal is not to list every feature, but to teach you the habits that make Claude Code genuinely useful instead of frustrating.

The Context Window Is Your Most Precious Resource

Before diving into specific best practices, you need to understand the single biggest factor in Claude Code performance: the context window. Claude can hold a lot of information in its working memory, but that memory is finite. As the window fills with code, conversation, and tool outputs, performance degrades.

Think of it like a desk. A clean desk lets you focus on the task at hand. A cluttered desk full of old papers, coffee cups, and sticky notes makes everything slower. The same principle applies to Claude Code sessions. The more irrelevant context sitting in the window, the harder it becomes for Claude to find what matters.

This is why so many of the best practices in this guide revolve around keeping the context window lean. Clearing between tasks, using subagents for investigation, and writing focused CLAUDE.md files all serve this one goal. When you manage context well, Claude Code feels fast and accurate. When you do not, it feels sluggish and forgetful.

The context window is not just about size. It is about relevance. A window full of relevant code and conversation is productive. A window full of stale exploration, failed attempts, and off-topic chatter is toxic. Every best practice in this guide either fills the window with useful information or keeps junk out of it.

You can monitor context usage by watching Claude’s responses. When Claude starts forgetting things you mentioned earlier, missing obvious connections, or producing generic output instead of code that fits your project, the context window is likely too full. These are signals that it is time to /clear or /compact. Ignoring these signals leads to a death spiral where each turn gets worse because the context gets noisier.

Another signal is response latency. When the context window is nearly full, Claude takes longer to process each turn because it has to reason over more information. If you notice responses getting slower without any change in task complexity, check whether the session has accumulated too much history. Clearing the session often restores the speed you saw at the start.

Give Claude a Way to Verify Its Work

Claude has a natural tendency to stop when work looks done. It writes a function, sees the code on screen, and considers the task complete. But looking done and being done are different things. The function might have a syntax error, a missing import, or a logic bug that only a test can catch.

The fix is one of the most powerful best practices in this guide: give Claude a verification check that returns pass or fail. Instead of hoping the code works, you create a feedback loop where Claude can self-iterate until the check passes. This transforms Claude from a code generator into a code generator that tests its own output.

There are four levels of verification gating, each more robust than the last. Level one happens in a single prompt. You ask Claude to run a check and iterate in the same message. For example, instead of saying “implement a function that validates email addresses,” you say “write a validateEmail function. Example test cases: user@example.com is true, invalid is false. Run the tests after implementing.”

Level two spans an entire session. You set the check as a goal condition using the /goal command. Claude keeps working until that goal is met, running checks along the way. This is useful for longer tasks where you want Claude to iterate without hand-holding.

Level three is a deterministic gate. You configure a Stop hook that runs your check as a script. The hook blocks the turn from completing until the check passes. Claude Code does override this after 8 consecutive blocks, so it cannot loop forever. This is the most reliable form of verification because it does not depend on Claude remembering to check.

Level four brings in a second opinion. You use a verification subagent or a dynamic workflow to review the work independently. This catches issues that the original session might be blind to. For critical code paths, a second set of eyes is one of the best practices you can adopt.

A concrete example makes this clearer. Suppose you ask Claude to add input validation to a user registration endpoint. Without a verification check, Claude writes the validation code, declares the task done, and moves on. The code might have a regex that rejects valid email addresses, or it might miss an edge case like Unicode characters in usernames. With a verification check, you tell Claude to write test cases for valid emails, invalid emails, edge cases, and run them. Claude writes the validation, writes the tests, runs them, sees failures, and iterates until everything passes. The result is code that actually works.

The verification best practices are not about distrusting Claude. They are about giving Claude the same feedback loop that human developers use. No developer considers their work done without running tests. Claude should not either.

Explore First, Then Plan, Then Code

One of the most common mistakes developers make is jumping straight into implementation. They describe what they want, Claude starts writing code, and twenty minutes later nothing works because nobody understood the existing codebase first. The explore-plan-code workflow prevents this.

Phase one is exploration. You enter plan mode and let Claude read and understand the code. No changes are made. Claude reads files, traces dependencies, and builds a mental model of how things work. This is where Claude learns the patterns, conventions, and architecture of your project.

Phase two is planning. Still in plan mode, Claude creates an implementation plan. You can press Ctrl+G to open the plan in your editor, review it, and make adjustments. This is your chance to catch misunderstandings before any code is written. A good plan lists which files change, what functions are added, and how the pieces fit together.

Phase three is implementation. You exit plan mode and Claude executes the plan. Because the exploration and planning phases already filled the context with relevant information, the implementation phase tends to go smoothly and produce better results.

Phase four is committing. You save the work with a descriptive commit message. This clears the slate for the next task.

Not every task needs all four phases. A typo fix, a log line change, or a variable rename can skip straight to implementation. Planning is for multi-file changes, unfamiliar code, or anything with architectural implications. Use your judgment. When in doubt, plan.

A common planning mistake is letting the plan grow too detailed. A good plan is a roadmap, not a script. It should list which files change and what the high-level approach is, not every line of code that will be written. If the plan is too detailed, Claude treats it as a constraint rather than a guide, and the implementation becomes rigid. Keep plans at the level of “add a resetToken model, create a POST endpoint at /api/reset, send an email with a token link.” Let Claude figure out the details during implementation.

Another mistake is skipping the review step. After Claude generates a plan, always read it. Press Ctrl+G, open it in your editor, and check whether it makes sense. Does it touch the right files? Does it follow your project’s patterns? Does it miss anything obvious? Catching a planning error takes thirty seconds. Catching an implementation error caused by a bad plan takes thirty minutes.

Provide Specific Context in Your Prompts

Vague prompts produce vague results. One of the simplest best practices to adopt is making your prompts specific. There are four strategies that consistently improve output quality.

Strategy one is scoping the task. Instead of “write tests,” say “write a test for foo.py covering the edge case where the user is logged out. Avoid mocks.” The scoped version tells Claude exactly what to test, which file to target, and what constraints to respect. Claude does not have to guess.

Strategy two is pointing to sources. Instead of “explain the API,” say “look through ExecutionFactory’s git history and summarize how its api came to be.” Claude reads the git log, traces the changes, and gives you a grounded answer based on actual history rather than speculation.

Strategy three is referencing existing patterns. Instead of “create a widget,” say “look at how existing widgets are implemented. HotDogWidget.php is a good example.” Claude reads the example file, extracts the pattern, and follows it. This produces code that fits your codebase instead of generic boilerplate.

Strategy four is describing the symptom. Instead of “fix the login bug,” say “users report that login fails after session timeout. Check the auth flow in src/auth/.” You give Claude the user-facing symptom and a starting location. Claude traces the issue from there.

All four strategies share a common thread: they reduce ambiguity. The less Claude has to guess, the better the output. Specific context is not about writing longer prompts. It is about writing prompts that leave no room for misinterpretation.

You can combine strategies for even better results. A prompt that scopes the task, points to a source file, references an existing pattern, and describes the symptom gives Claude everything it needs in one message. For example: “Write a test for the authenticate function in auth.py. Look at how test_user.py tests the login function for the pattern. Users report that authentication fails when the password contains special characters. Avoid mocking the database.” This prompt uses all four strategies and gives Claude a clear, unambiguous target.

The cost of a vague prompt is not just a bad first response. It is the entire correction cycle that follows. You get a bad response, you explain what went wrong, Claude tries again, you correct again. Each correction fills the context window with failed attempts and corrections. By the time you get a good response, the context is polluted and subsequent tasks suffer. A specific prompt gets it right the first time and keeps the context clean.

Configure Your Environment with CLAUDE.md

CLAUDE.md is a file that Claude Code loads at the start of every session. It acts as a persistent instruction sheet, telling Claude about your project, your conventions, and your preferences. Writing a good CLAUDE.md is one of the highest-impact best practices you can adopt.

Run /init in your project root to generate a starter file. Claude will analyze your codebase and produce a reasonable first draft. From there, you edit and prune until the file contains only broadly useful information.

What to Include in CLAUDE.md

The file should contain things Claude cannot figure out by reading code. This includes bash commands that are specific to your project, code style rules that differ from defaults, testing instructions, repository etiquette, and architectural decisions that are not obvious from the code structure.

One trick that improves adherence: add the words IMPORTANT or YOU MUST before critical instructions. Claude gives these phrases extra weight and is more likely to follow them. For example, “YOU MUST run npm test before considering any task complete” is stronger than “run npm test before finishing.”

The biggest mistake people make with CLAUDE.md is overloading it. Every line in the file consumes context window space on every session. If you include things Claude could figure out by reading code, you are wasting context for no benefit. Prune ruthlessly. A lean CLAUDE.md is a good CLAUDE.md.

See the official best practices documentation from Anthropic for the complete reference on configuring your environment.

CLAUDE.md should evolve with your project. When you notice Claude repeatedly making the same mistake, add a line to CLAUDE.md that prevents it. When you notice a line in CLAUDE.md that Claude never needs, remove it. Treat the file as a living document that gets better over time. Review it every few weeks and ask whether each line is still earning its place in the context window.

For monorepos or large projects, you can place CLAUDE.md files in subdirectories. Claude Code reads the root CLAUDE.md plus any CLAUDE.md in the current working directory. This lets you have project-wide best practices in the root file and module-specific instructions in subdirectories. A frontend module might have different testing conventions than a backend module, and nested CLAUDE.md files handle this cleanly.

Configure Permissions to Reduce Interruptions

Nothing breaks your flow like a permission prompt in the middle of a complex task. Claude Code asks for permission before running commands that could modify your system. This is safe by design, but it gets annoying fast when you keep approving the same commands.

There are three ways to reduce permission interruptions, and using them well is one of the best practices that separates new users from experienced ones.

Option one is auto mode. A classifier model evaluates each command and blocks only the risky ones. Safe commands like ls, cat, and git status run without prompts. Commands that could delete files, modify system state, or push to remotes still ask. Auto mode is a good default for most developers.

Option two is permission allowlists. You explicitly permit specific tools and commands. For example, you can allow npm run lint and git commit without prompts, while everything else still asks. This gives you fine-grained control over what runs automatically.

Option three is sandboxing. Claude Code runs inside an OS-level isolation layer that prevents it from touching anything outside the sandbox. This is the most secure option and is useful for untrusted codebases or CI environments.

The right permission configuration depends on your risk tolerance. For personal projects on your own machine, auto mode is usually fine. You trust the codebase, you trust Claude, and the cost of an unwanted command is low. For production codebases, shared repositories, or CI pipelines, allowlists give you the control you need. Only allow commands you have reviewed and approved. Sandboxing is the right choice when you are working with code you did not write, such as open source contributions or contractor deliverables.

Whatever you choose, review your permission settings periodically. As your project evolves, you might add new scripts that should be allowlisted, or remove old ones that are no longer needed. Stale permission settings are a minor security risk and a minor annoyance, but keeping them current is one of those best practices that pays off over time.

Use CLI Tools and MCP Servers

Claude Code can call CLI tools directly, and this is one of the most context-efficient best practices available. Instead of reading documentation into the context window, Claude runs a command and gets the answer in a compact response.

Tools like gh, aws, gcloud, and sentry-cli are especially useful. Claude can run gh pr list to see open pull requests, aws s3 ls to check S3 buckets, or sentry-cli issues list to find production errors. Each command returns structured data that takes far less context than reading the equivalent web interface.

Claude can also learn unknown CLI tools. If you have a custom tool, just tell Claude about it:

Use 'foo-cli-tool --help' to learn about foo tool.

Claude will run the help command, read the output, and figure out how to use the tool. This works for any well-documented CLI.

MCP (Model Context Protocol) servers extend Claude Code with additional capabilities. You connect them with the claude mcp add command. MCP servers can provide database access, API integrations, file system tools, and more. They are a powerful way to give Claude domain-specific abilities without bloating the context window.

Common MCP use cases include connecting to a PostgreSQL database so Claude can run queries, integrating with Jira or Linear for issue tracking, or connecting to a cloud provider API for infrastructure management. Each MCP server runs as a separate process, so it does not consume Claude’s context window until Claude actually calls it. The result is on-demand access to external tools without the context overhead of loading documentation.

Set Up Hooks for Deterministic Automation

CLAUDE.md is advisory. Claude reads it and tries to follow the instructions, but it might forget or skip them. Hooks are different. They are deterministic scripts that run every single time, regardless of what Claude decides to do.

This makes hooks one of the best practices for enforcing rules that must never be skipped. If you want eslint to run after every file edit, a hook guarantees it. If you want tests to run before every commit, a hook guarantees that too.

Claude can write hooks for you. Just ask:

Write a hook that runs eslint after every file edit.

Claude will generate the hook script and show you where to put it. Hooks live in .claude/settings.json. You can also run /hooks in Claude Code to browse existing hooks and see what they do.

The key difference between hooks and CLAUDE.md instructions is reliability. A CLAUDE.md instruction that says “run eslint after edits” might be followed 90% of the time. A hook that runs eslint after edits is followed 100% of the time. For critical checks, always use hooks.

Hooks shine in team settings. When multiple developers use Claude Code on the same project, you cannot guarantee they will all follow CLAUDE.md instructions perfectly. But hooks in the shared .claude/settings.json file run for everyone. This makes hooks one of the best practices for enforcing project standards across a team without relying on individual discipline.

Create Skills and Custom Subagents

Two of the more advanced best practices involve creating reusable components: skills and subagents. Both let you codify workflows so you do not have to reinvent them every session.

Skills

Skills are SKILL.md files that live in .claude/skills/. Each file describes a workflow that Claude can invoke. You trigger a skill with a slash command like /skill-name. Skills are useful for repeated workflows like deploying a service, running a code review, or generating boilerplate.

One important detail: if a skill has side effects (like deploying code or modifying production), set disable-model-invocation: true in the skill file. This prevents Claude from running the skill automatically without your explicit command.

Custom Subagents

Subagents live in .claude/agents/. Each subagent definition includes a name, description, available tools, and model. For example, you can define a security-reviewer subagent that only has access to Read, Grep, Glob, and Bash, and runs on the Opus model for deeper reasoning.

name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus

Subagents run in their own context window. This means they can investigate complex questions without polluting your main session. When the subagent finishes, it returns a summary. The full investigation stays in the subagent’s context, which is discarded after it completes. This is one of the best practices for keeping your main context clean while still doing deep investigation.

When should you create a custom subagent versus just asking Claude directly? The answer is about frequency and isolation. If you find yourself repeatedly asking Claude to perform the same type of investigation, like security reviews or dependency audits, create a subagent. The subagent has the right tools and model pre-configured, so you do not have to specify them each time. And because it runs in its own context, the investigation details never clutter your main session.

Communicate Effectively: Let Claude Interview You

Sometimes you know what you want to build but not how to describe it. The prompt is too vague because the problem has too many dimensions. In these cases, one of the best practices is to flip the dynamic: let Claude interview you.

Use this prompt pattern:

I want to build [description]. Interview me in detail using
the AskUserQuestion tool. Ask about technical implementation,
UI/UX, edge cases, concerns, and tradeoffs.

Claude will ask you a series of targeted questions. Each question narrows the scope. By the end of the interview, Claude has a detailed understanding of what you want, and you have thought through aspects you might have missed.

After the interview, start a fresh session. The old session’s context is full of interview chatter. A clean session starts with just the gathered requirements, which keeps the context lean and the implementation focused. This two-step pattern, interview then implement, is one of the best practices for complex feature work.

The interview approach also surfaces requirements you did not think of. Claude asks about error handling, edge cases, performance, and security because those are the dimensions that matter in production code. By answering these questions up front, you give Claude a complete picture of what success looks like. The implementation phase then has everything it needs to produce code that handles real-world conditions, not just the happy path.

Manage Your Session Like a Pro

Session management is not glamorous, but it is one of the best practices that separates smooth workflows from painful ones. Claude Code gives you several tools for controlling the session, and knowing when to use each is essential.

Pressing Esc stops Claude mid-action. If Claude is going down a wrong path, do not wait for it to finish. Stop it immediately. Every token Claude spends on the wrong direction is context window space you cannot get back.

Esc+Esc or /rewind restores the previous state. This is useful when Claude made changes you want to undo. You can rewind to before the changes were made and try a different approach.

/clear resets the session entirely. The context window is emptied and Claude starts fresh. Use /clear between unrelated tasks. If you just finished debugging a database issue and now want to work on the UI, clear the session first. The database context is irrelevant to the UI work and will only slow Claude down.

The two-correction rule is one of the most practical best practices in this section. If you correct Claude on the same issue twice, stop. Do not correct a third time. Instead, /clear the session and start over with a better prompt that prevents the issue from the start. Correcting repeatedly teaches Claude the wrong lesson and wastes context.

/compact does a partial compaction. It summarizes the current context into a shorter form, freeing up space without fully resetting. Use this when the session is getting long but the earlier context is still relevant.

/btw lets you ask side questions without derailing the main task. If Claude is implementing a feature and you suddenly want to know how a different part of the codebase works, /btw lets you ask without mixing that exploration into the implementation context.

Choosing between /clear and /compact is a judgment call that comes with practice. Use /clear when the current context is no longer relevant to what comes next. Use /compact when the context is still relevant but too large. If you are halfway through a feature and the context is getting heavy, /compact preserves the key decisions and code while discarding the exploration noise. If you just finished the feature and want to start on something new, /clear is the right choice because nothing from the old task is relevant.

Scale with Subagents, Non-Interactive Mode, and Worktrees

The best practices in this section are for when you need to go beyond a single interactive session. They let you parallelize work, automate repetitive tasks, and run multiple Claude instances simultaneously.

Use Subagents for Investigation

When you need to understand a complex part of your codebase, delegate the investigation to a subagent:

Use subagents to investigate how our authentication
system handles token refresh.

The subagent reads files, traces code paths, and returns a summary. Your main session stays clean. This is one of the best practices for keeping context lean during complex investigations.

Non-Interactive Mode

Claude Code can run without an interactive session. This is useful for scripts, CI pipelines, and batch operations:

claude -p "Explain what this project does"
claude -p "List all API endpoints" --output-format json

The -p flag runs Claude in print mode. It takes a prompt, processes it, prints the result, and exits. You can pipe the output to other tools or save it to a file. The --output-format json flag gives you structured output that is easy to parse programmatically.

Run Multiple Sessions with Worktrees

Git worktrees let you have multiple checkouts of the same repository. You can run Claude Code in each worktree independently. This enables the writer-reviewer pattern: Session A implements a feature in one worktree, Session B reviews the changes in another.

This pattern is one of the best practices for code quality. The reviewer session has fresh context and no attachment to the implementation. It catches issues the writer session is blind to because the writer is too close to the code.

Fan Out Across Files

For repetitive tasks across many files, you can script Claude Code to process each file independently:

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL."
done

Each file gets a fresh session with no context pollution from other files. This is one of the best practices for large-scale migrations, refactors, or batch updates.

The fan-out pattern works because each file is independent. There is no shared state between sessions. If one file fails, the others still succeed. You can collect the OK and FAIL results, review the failures, and re-run just those files with a more specific prompt. This is far more reliable than trying to migrate all files in a single interactive session, where errors in one file cascade and pollute the context for the rest.

For very large codebases, you can parallelize the fan-out. Run multiple Claude instances simultaneously, each processing a different batch of files. This requires more compute resources but can turn a multi-hour migration into a multi-minute one. The key is to keep each session focused on one file so the context stays lean and the results stay accurate.

Avoid Common Failure Patterns

The best practices in this section are about what not to do. These are the failure patterns that Anthropic engineers see repeatedly, and avoiding them will save you hours of frustration.

The kitchen sink session is the most common failure. You start a session, work on a bug fix, then pivot to a feature, then check some documentation, then debug a test. The context window fills with unrelated information. Claude becomes confused about what task is current. The fix is simple: /clear between tasks. Every time you switch to an unrelated task, clear the session.

Correcting over and over is the second failure pattern. Claude does something wrong, you correct it. It does something else wrong, you correct again. Each correction adds context, and the context makes things worse, not better. After two corrections on the same issue, stop. Clear the session and start fresh with a better prompt that prevents the issue from the start.

An over-specified CLAUDE.md is the third failure pattern. People treat CLAUDE.md like a documentation file and fill it with everything they know about the project. The file grows to thousands of words, every session loads it, and the context window starts each session already half full. The fix is to prune ruthlessly. If Claude can figure it out by reading code, it does not belong in CLAUDE.md.

The trust-then-verify gap is the fourth pattern. You ask Claude to do something, it says it is done, and you trust it without checking. Sometimes the code does not even compile. The fix is one of the core best practices from earlier in this guide: always provide a verification check. If there is no check, there is no done.

Infinite exploration is the fifth pattern. Claude reads file after file, traces dependency after dependency, and never converges on an answer. The context window fills with exploration data and the actual task is never addressed. The fix is to scope narrowly or use subagents. A subagent can explore and return a summary, keeping the main context clean.

Recognizing these patterns in your own workflow takes practice. The best signal is how you feel during a session. If you are correcting Claude repeatedly, something is wrong with the prompt or the context. If Claude seems to forget things you said five minutes ago, the context is too full. If Claude is reading files without making progress, the task is underspecified. Pay attention to these signals and apply the corresponding fix before the session spirals.

A Worked Example

Let us walk through a realistic scenario that ties together several best practices from this guide. Imagine you need to add a password reset feature to an existing web application. This is a multi-file change that touches authentication, email sending, and the database schema. It is exactly the kind of task where best practices make the difference between a smooth implementation and a frustrating one.

You start by entering plan mode. Claude explores the codebase, reading the existing authentication code, the email sending module, and the database migration files. No changes are made yet. Claude builds a mental model of how authentication works, how emails are sent, and how the database is structured.

Next, Claude creates an implementation plan. You press Ctrl+G to open it in your editor. The plan lists three files to modify: auth.py for the reset request endpoint, email.py for the reset email template, and a new migration file for the reset token table. You review the plan, notice that Claude forgot to include rate limiting, and add a note about it.

Now you exit plan mode and Claude starts implementing. It writes the reset token model, the request endpoint, and the email template. After each file, Claude runs the test suite you defined as a Stop hook. The first run fails because the email template is missing a required field. Claude fixes the template, runs the tests again, and they pass.

Halfway through, you realize you forgot to specify how reset tokens should expire. Instead of correcting Claude mid-implementation, you press Esc to stop it, then use /btw to ask a side question about token expiration policies in the existing codebase. Claude finds that session tokens expire after 24 hours. You decide reset tokens should expire after 1 hour. You add this to the plan and let Claude continue.

When the implementation is done, you start a second session in a different git worktree. This session reviews the changes with fresh context. It catches a subtle issue: the reset endpoint does not check whether the user account is active before sending a reset email. You fix this in the original session, run the tests one more time, and commit.

Throughout this example, multiple best practices worked together. Plan mode prevented blind implementation. The verification hook caught the missing email field. The /btw command let you ask a side question without derailing the session. The two-session writer-reviewer pattern caught a security issue. And /clear between the implementation and review sessions kept the reviewer’s context clean.

This is what good best practices look like in practice. Not every task needs all of these techniques, but knowing when to reach for each one is what makes the difference. The goal is not to follow a checklist mechanically. The goal is to develop habits that keep the context window clean, the verification reliable, and the workflow smooth.

Best Practices: Common Mistakes to Avoid

Even developers who know these best practices sometimes fall into bad habits. Here are four mistakes that consistently cause problems, along with their consequences and fixes.

• Never clearing the session. Context fills with stale exploration and failed attempts, degrading performance with every turn. Fix: run /clear between every unrelated task, no exceptions.
• Trusting without verifying. Claude says the code is done but tests were never run, and the build is broken. Fix: always provide a verification check, whether a test command, a build script, or a Stop hook.
• Stuffing CLAUDE.md with everything. Every session loads thousands of words of unnecessary context, wasting the context window from turn one. Fix: include only what Claude cannot figure out by reading code. Prune regularly.
• Correcting the same issue three times. Each correction adds noise to the context, making Claude more confused, not less. Fix: after two corrections, /clear and restart with a better prompt that prevents the issue.

Best Practices: Best Practices

• Clear the context window between unrelated tasks using /clear to keep Claude focused and fast.
• Always provide a verification check so Claude can self-iterate instead of guessing when work is done.
• Use plan mode for multi-file changes to explore and plan before writing any implementation code.
• Keep CLAUDE.md lean by including only information Claude cannot discover by reading the codebase itself.
• Delegate investigation to subagents so deep exploration does not pollute your main session context.

Best Practices: Frequently Asked Questions

How often should I clear my Claude Code session?

Clear between every unrelated task. If you switch from debugging to feature work, run /clear. Stale context degrades performance and causes Claude to reference irrelevant information from earlier tasks.

What should I put in my CLAUDE.md file?

Include only what Claude cannot figure out by reading code: custom build commands, non-standard style rules, testing instructions, and architectural decisions. Exclude anything Claude can discover on its own or information that changes frequently.

When should I use plan mode instead of direct implementation?

Use plan mode for multi-file changes, unfamiliar codebases, or tasks with architectural implications. Skip it for trivial fixes like typos, log line changes, or simple variable renames where the path is obvious.

How do Stop hooks improve verification?

Stop hooks run your check as a deterministic script that blocks the turn from completing until the check passes. Unlike advisory CLAUDE.md instructions, hooks cannot be skipped. Claude Code overrides after 8 consecutive blocks.

What is the two-correction rule?

If you correct Claude on the same issue twice, stop. Do not correct a third time. Instead, /clear the session and restart with a better prompt that prevents the issue from occurring in the first place.

Best practices for Claude Code all serve one goal: keeping the context window lean and the verification reliable. Clear sessions between tasks, give Claude a way to check its own work, use plan mode for complex changes, and keep CLAUDE.md short. These habits compound over time.