Claude Code Best Practices

Get more finished work from Claude Code by making success testable, keeping each session focused, and automating the rules you keep repeating. For a developer or small team a few weeks in, that is the adoption order that matters. Add parallel workers after a single session can reliably finish a bounded task.

The practices below build on Anthropic's Claude Code best practices and the linked product documentation. The order, examples, and savings framework are editorial recommendations for a small team, not an Anthropic productivity benchmark.

The Order to Adopt Them

Start at the top and stop adding machinery when the problem is solved. Each habit targets a different kind of waste.

The savings column describes the intended benefit. It does not promise a fixed reduction in tokens, time, or spend.

1. Give Claude a Way to Prove the Change Works

Define the check before requesting the change. Claude can use test results, build output, or a screenshot comparison to find mistakes and continue working. Ask it to show the evidence at the end. Anthropic: verification.

Do this: for a developer fixing duplicate form submissions, specify the behavior you need: repeated clicks must create only one record. Supply the relevant file, reproduction steps, and a check that would fail on the current implementation.

An example task brief:

Fix duplicate submissions in the checkout form. Reproduce the failure with a test, preserve the existing validation behavior, then run the relevant tests. Report the command, result, and anything you could not verify.

Command: npm test, if your repository defines that script. Replace it with the project's actual test command, including any required setup. A command that fails because dependencies or fixtures are missing is an environment problem to resolve, not proof that the change is wrong.

For a UI change, add a reference screenshot and ask Claude to capture the running result through an available browser tool. Check layout visually and behavior with tests. Neither check covers the other completely.

What it saves: the developer stops being the messenger between every failed attempt and the next correction. Keep human review for whether the acceptance criteria were right.

2. Use Plan Mode When the Approach Is Uncertain

Review the proposed change before buying a large implementation. Start with claude --permission-mode plan, or cycle into Plan mode with Shift+Tab. Claude can inspect the project and propose work before editing source files. Anthropic: plan before editing.

Do this: a team adding an authentication provider could ask for the affected files, callback flow, failure cases, migration needs, and verification steps. Then correct the plan while the disagreement is still cheap.

Command: claude --permission-mode plan.

For that authentication change, the useful review questions are specific: does the plan reuse the existing session code, preserve existing login methods, and test an expired callback? Approve the approach once those questions have answers, then move into implementation.

Skip a formal plan for an obvious typo or a narrowly specified edit. Planning has its own cost; use it when a wrong choice would create meaningful rework. Anthropic: when planning helps.

What it saves: discarded diffs and the review time spent discovering that the code solved a different problem.

3. Keep CLAUDE.md Short and Specific

Put durable team guidance in a project CLAUDE.md. Use it for the test command, non-obvious environment setup, architectural boundaries, and conventions that differ from the obvious defaults. Claude loads these instructions as context. Anthropic: project memory.

Do this: a small team whose sessions repeatedly use the wrong package manager could record the correct command and the reason it matters. A team with generated API clients could record where the source schema lives and how clients are regenerated.

File: CLAUDE.md in the project root, reviewed alongside the code it describes.

Keep temporary task details in the task brief. Delete stale rules when the project changes. A useful line prevents a recurring mistake; a generic instruction to produce excellent code adds little direction.

Distinguish this file from auto memory, the notes Claude writes from experience. Auto memory is local to the machine and shared across that repository's worktrees. It is not automatically your teammates' shared handbook. Use /memory to inspect or edit it. Anthropic: auto memory.

What it saves: repeated onboarding inside every session. Our CLAUDE.md guide covers the file structure and cleanup routine.

4. Clear Between Jobs, Compact Within a Job

Treat the context window, the material Claude can use in the current conversation, like a working desk. Keep the documents for the current job on it. A finished incident investigation does not need to accompany the next CSS change.

Do this: save the useful decisions and remaining task details, then start unrelated work with /clear. For a long task you are continuing, /compact summarizes the conversation; you can tell it which decisions and test results to preserve. Anthropic: context commands.

Command: /clear when the job changes.

For a developer stuck in repeated failed fixes, first extract a better brief: what actually fails, which approaches were ruled out, and the next check. Restart with that brief. Clearing without preserving what you learned simply creates another discovery session.

Use /context when you need to inspect what is consuming space. A large context window is capacity, not a reason to keep unrelated material. Anthropic: command reference.

What it saves: unnecessary context and repeated reasoning about stale approaches. Compaction preserves a summary, so keep exact requirements and commands in a file when losing detail would matter.

5. Measure Cost per Accepted Change

Track whether a task finished successfully alongside its usage. /usage shows session usage and, for subscribers, plan usage information. API dollar figures are estimates; consult the billing console for the authoritative charge. Record the session result before clearing, because current versions reset session totals with /clear. Anthropic: cost tracking.

Do this: a team lead could keep a small ledger with task type, model, usage, human correction time, and whether the change was accepted. Compare similar bug fixes with similar bug fixes, rather than comparing an easy rename with a difficult migration.

Command: /usage.

Use this accounting rule for a pilot:

Cost per accepted change = (tool cost allocated to the work + human review and rework cost) ÷ accepted changes.

Before adopting these habits, record that baseline. Afterward, include the time spent maintaining instructions and hooks. A smaller model bill is not a saving if a teammate spends longer rescuing the result. On a fixed subscription, fewer tokens may create room for more work without changing the monthly fee.

You can change models with /model. Anthropic positions Sonnet for daily coding, Opus for complex reasoning, and Haiku for simple tasks. Treat that as a starting point for your own task comparisons. Anthropic: model configuration.

What it saves: unnecessary upgrades and expensive defaults that persist after the hard part is over. Use our Claude Code pricing guide when you are ready to compare billing options.

6. Set Permissions Before Approval Fatigue Sets In

Choose which actions should run freely and which deserve your attention. /permissions exposes allow, ask, and deny rules; these are enforced by Claude Code independently of the instructions in your prompt. Anthropic: permissions.

Do this: a developer repeatedly approving the same local lint command could allow that specific command after checking what it does. A team lead could retain an explicit approval requirement for publishing changes. Avoid a broad shell allowance just to silence one repetitive prompt.

Command: /permissions.

Know the mode you are in. Manual mode prompts for most edits and commands. acceptEdits approves edits and common filesystem operations. Auto mode delegates action review to a classifier. The starting mode depends on version, settings, availability, and organization policy, so check the mode indicator instead of assuming every installation behaves alike. Anthropic: permission modes.

What it saves: attention spent approving routine work. It does not establish that the implementation is correct. Our Claude Code Auto Mode guide explains that separate decision.

7. Put Mandatory Actions in Hooks

Move a repeatable rule into executable configuration when reminding Claude is no longer good enough. Command hooks are scripts Claude Code runs at configured events. They can automate formatting or validate a proposed action. Anthropic: automating with hooks.

Do this: a team that repeatedly catches edits to generated files could implement a PreToolUse check for the relevant editing tools. It should reject the targeted action with a useful explanation and point to the source file that should change instead.

File: .claude/settings.json, with a project hooks configuration. Inspect the loaded configuration with /hooks.

Choose the event carefully. A PreToolUse hook can stop a matched action before execution. A PostToolUse hook runs after it, so it cannot prevent the action that already happened. Matching Edit and Write does not cover a shell command that writes the same file. Anthropic: hook events and decision control.

Test both an allowed action and a rejected action before relying on the rule. Keep checks narrow enough that ordinary edits do not trigger a slow, unrelated test suite.

What it saves: repeated reminders and preventable cleanup. A hook's reliability is limited by the script and events it covers. Our Claude Code hooks configuration guide covers configuration details.

8. Use Subagents for Bounded Investigation

Delegate a research question when its intermediate output would crowd the main conversation. Subagents work in separate contexts and return results. Their requests still count toward your usage limits. Anthropic: subagents.

Do this: a developer tracing an intermittent login failure could ask a subagent to inspect the refresh path and return the relevant files, evidence, and unresolved questions. Keep the main session focused on choosing and implementing the fix.

For example:

Use a subagent to trace the expired-session path. Do not edit files. Return the relevant file locations, the checks already present, and the gaps you found.

File: a Markdown definition under .claude/agents/ when this becomes a recurring role. Configure tools appropriate to that role, such as read-only tools for investigation. A one-off request does not need a custom agent file.

What it saves: space in the main conversation and time reading intermediate exploration. It can add total usage through delegation and duplicate investigation, so give it one question and a bounded output. Our subagents guide explains when a reusable specialist is worth creating.

9. Add Worktrees Only for Independent Work

Give simultaneous editing sessions separate working directories. A Git worktree is another checkout with its own files and branch, sharing repository history. It prevents one session's edits from appearing underneath the other. Anthropic: worktrees.

Do this: a small team could run an isolated feature task while another session fixes an unrelated bug. Define the boundary of each task and name who will review and integrate the results.

Command: claude --worktree feature-auth. Use a different worktree name in the second terminal.

A fresh checkout still needs dependencies and the required development environment. Verify those before judging its test results. The repository also needs an existing commit. Anthropic: worktree setup, parallel session workflow.

What it saves: waiting when tasks are independent, and recovery from shared-file interference. It does not remove merge review, integration tests, or the cost of running another session. If both tasks redesign the same interface, settle that interface first.

Two Small Tools Worth Building After the Basics

Build only around a problem that remains visible in your team's records. These are product hypotheses, not proven businesses.

A session cost ledger is the strongest opportunity. A development lead could use it to connect task outcomes with usage and human rework. A DataForSEO snapshot retrieved on October 11, 2026 estimated 4,400 US monthly Google searches for “claude code cost.” That is evidence of cost interest, not willingness to pay. The Keyword Overview API describes the metric source.

The smallest useful version is a task form plus usage imports or manual entries, grouped by task type and billing arrangement. A team might pay for consistent reporting across projects. The catch is attribution: an estimated session cost, a subscription fee, and a human's time are different measures. Keep them separate before combining them into a decision.

A repository readiness check could sell as team setup and maintenance. The same DataForSEO snapshot estimated 1,900 US monthly searches for “claude code best practices.” A small agency or engineering team could pay for a check that finds stale test commands, missing prerequisites, contradictory instructions, and hooks that no longer work.

Start with one repository and a report a developer can verify. The catch is that a generic template is easy to copy; the valuable work is keeping the checks accurate as the repository changes. Neither search estimate proves demand for these exact products. Validate the problem with actual teams before building a dashboard.

What These Habits Cannot Fix

They cannot supply a missing product decision, make a weak test suite comprehensive, or turn a permitted action into a correct one. A session can efficiently produce the wrong feature if the brief never established what the user needed.

My recommendation is to treat the first four habits as the foundation. Add measurement immediately, then introduce permissions, hooks, delegation, and parallelism where your team's repeated failures justify them. More configuration is maintenance work too.

Will these habits lower my monthly Claude Code bill?

They can reduce avoidable usage and rework. On a fixed subscription, that may mean more useful work within the same allowance rather than a lower invoice. On metered usage, compare actual charges for comparable accepted work. Keep human correction time in the comparison. Anthropic: costs.

Does the session dollar estimate mean I owe that amount?

No. Claude Code's displayed session cost is an estimate of API usage, not a separate bill for a subscriber. Use the billing console for authoritative API charges and your plan's usage view for the allowance you are consuming. Anthropic: usage reporting.

Should I upgrade to a larger plan before changing my workflow?

Upgrade when useful, well-scoped work is consistently constrained by the allowance and the extra capacity is worth its price. First check whether failed approaches, repeated setup, or unnecessary concurrent sessions are consuming that allowance. A larger plan buys room; it does not decide how to use it.

Your Monday Move

Pick one recurring task, such as a small bug fix, and run it with a written acceptance check and a focused brief. Record the result, usage, and correction time. Put only the reusable lesson in CLAUDE.md. Repeat that workflow before adding another agent.

If your team needs these checks and workflows built into its development process, we build AI production systems.