Claude Code is powerful enough to make significant changes to a codebase in minutes. That power produces great results when the right practices are in place, and frustrating, hard-to-reverse changes when they are not.
These 10 practices cover the full workflow: project setup, session management, task specification, and output review. Each one addresses a specific failure mode that experienced Claude Code users have encountered.
The gap between a productive Claude Code session and a frustrating one is rarely about the model. It is almost always about how the session was set up.
The 10 practices
| Practice | Why It Matters | What Happens Without It |
|---|---|---|
| 1. Write a CLAUDE.md before starting | Gives Claude Code accurate context about the project | Claude guesses conventions and makes inconsistent choices |
| 2. Use plan mode for large changes | Lets you review and reject the plan before execution | Unwanted changes are applied before you can stop them |
| 3. Commit before every session | Creates a safe revert point | There is no clean way to undo sweeping changes |
| 4. Be specific in instructions | Produces targeted, reviewable output | Vague prompts produce vague or random changes |
| 5. Use /compact on long sessions | Keeps context quality high | Outputs degrade and become inconsistent |
| 6. Scope tasks to one session | Produces clean, reviewable changesets | Long multi-goal sessions produce tangled diffs |
| 7. Read the diff before accepting | Catches errors before they enter the codebase | Technical debt accumulates silently |
| 8. Use MCP integrations | Gives Claude Code access to the tools it needs | Claude Code works around missing tools with worse solutions |
| 9. Use subagents for parallel tasks | Compresses timelines for independent work | Sequential execution takes longer than necessary |
| 10. Set working directory correctly | Ensures path resolution works throughout the session | File operations fail or target the wrong location |
Practice 1: Write a CLAUDE.md before starting any project
CLAUDE.md is a context file that Claude Code reads at the start of every session. It tells Claude Code what the project is, how it is structured, what conventions it follows, and what it should not touch.
Without a CLAUDE.md, Claude Code makes inferences from the codebase. Those inferences are often correct, but they are never as reliable as explicit instruction. A developer who does not write a CLAUDE.md is spending every session correcting mismatches between Claude Code’s assumptions and the project’s actual conventions.
What to include in CLAUDE.md:
- Tech stack and framework versions
- Directory structure and what lives where
- Naming conventions for files, functions, and variables
- Testing approach: which framework, where tests live, what coverage threshold applies
- Sections of the codebase that should not be modified automatically
- Environment setup notes
Keep CLAUDE.md under 500 words. A focused CLAUDE.md outperforms a comprehensive one.
Practice 2: Use plan mode for large changes
Plan mode asks Claude Code to describe what it intends to do before it does it. For any change that touches more than a handful of files, or any change to a critical part of the codebase, running in plan mode first is not optional.
The plan gives you the opportunity to correct misunderstandings before they become merged commits. It surfaces scope creep: Claude Code sometimes plans to modify things you did not intend to change. Reading the plan takes 2 minutes. Reviewing an unwanted 40-file changeset takes much longer.
Auto mode is appropriate for small, well-defined tasks on familiar codebases. For large refactors, greenfield builds, or any task touching production-critical logic, use plan mode.
Practice 3: Commit before every session
Every Claude Code session should begin with a clean git state. Commit all pending work before running Claude Code on a task. This creates a revert point: if the session produces changes you want to discard entirely, you can reset to the pre-session state without losing prior work.
Teams that skip this practice eventually run a session that produces a tangled changeset they want to undo, discover they have no clean revert point, and spend hours manually reversing changes. The commit takes 30 seconds. The recovery takes hours. See Claude Code common mistakes for the full breakdown of what happens when this step is skipped.
Practice 4: Be specific in instructions
Vague instructions produce vague output. "Improve the performance of this file" gives Claude Code no acceptance criteria to work toward.
"Reduce the database queries in the user dashboard endpoint from 12 to under 4 by implementing query batching and caching the role lookup" gives Claude Code a specific target and a specific approach.
Well-specified instructions include:
- What to change
- What not to change
- What the output should look like when the task is done
- Any constraints on the approach
The more specific the instruction, the more reviewable the output.
Practice 5: Use /compact to manage context on long sessions
Claude Code sessions have a context window. As the session grows, earlier context receives proportionally less attention. On a long session, outputs from hour three are less coherent than outputs from hour one.
The /compact command summarizes prior session context, freeing space for continued work. Use it when a session has been running for an extended period and you notice output quality declining. For sessions that will span multiple hours, use /compact proactively rather than waiting for degradation.
Practice 6: Scope tasks to one clear goal per session
“Build the whole app” is not a task. It is a project. Claude Code sessions produce the best results when the task is specific enough to be completed and reviewed in a single session.
A well-scoped session task: "Scaffold the authentication module: user model, login route, JWT generation, and token refresh. Do not touch the existing user profile endpoints." A poorly scoped session task: "Work on the backend." The first produces a reviewable changeset.
The second produces a sprawling diff that is difficult to evaluate.
Practice 7: Read the diff before accepting
Claude Code makes real changes to real files. Every change should be reviewed before it is committed. Reading the diff is not optional, even when the session went smoothly and the outputs look correct.
Claude Code occasionally makes changes outside the intended scope, removes comments that carry important context, or introduces subtle logic errors that are not visible from the high-level output. The diff review catches these before they enter the codebase. If you are not reviewing diffs, you are accumulating technical debt in changes you have not read.
Practice 8: Use MCP integrations to give Claude Code the tools it needs
MCP (Model Context Protocol) connects Claude Code to external tools: databases, APIs, file systems, GitHub, Slack, and more. When Claude Code has access to the tools it needs, it produces more accurate, more directly useful output.
Without MCP integrations, Claude Code works with what it can read from the local filesystem. With MCP integrations, it can query a live database, check a GitHub issue, read a Jira ticket, or access an API directly. The difference in output quality for workflows that depend on external context is significant.
Practice 9: Use subagents for parallel independent tasks
Claude Code supports parallel subagents: multiple agents working on independent tasks simultaneously. When a session has multiple independent workstreams, running them in parallel compresses total execution time.
A session that would take 45 minutes sequentially (generate tests, update documentation, write migration script) can run in 20 minutes with all three tasks running in parallel. The requirement is that the tasks are genuinely independent: they do not write to the same files or depend on each other’s outputs. See agentic workflows for the patterns that work best.
Practice 10: Set the working directory correctly
Claude Code should always be run from the project root directory. Path resolution for file reads, writes, and command execution is relative to the working directory. Running Claude Code from the wrong directory causes file operations to target incorrect paths, which either fails visibly or, worse, modifies files in the wrong location.
Before starting a session, verify you are in the working directory (project root). This is especially important in monorepos and multi-service repositories where developers frequently navigate between subdirectories.
Which practices matter most for your current stage
Just getting started with Claude Code
Practices 1 (CLAUDE.md), 3 (commit first), and 7 (read the diff) are the foundation. Get these three right before optimizing anything else. They prevent the most common and costly beginner mistakes.
Using Claude Code regularly but inconsistently
Practices 2 (plan mode), 4 (specific instructions), and 6 (scoped tasks) transform inconsistent results into reliable ones. Most developers who find Claude Code “unpredictable” are working without these practices.
Running Claude Code in a team environment
Practices 8 (MCP integrations), 9 (subagents), and 5 (/compact) become important at team scale. MCP connects Claude Code to shared tooling. Subagents parallelize team workflows. Context management prevents the quality degradation that frustrates teams on long collaborative sessions. For teams onboarding multiple engineers at once, the Claude Code course is a practical way to ensure everyone starts with the same session habits and avoids the most common mistakes.
Frequently asked questions
What should I always include in a CLAUDE.md file?
At minimum: your tech stack and versions, directory structure, naming conventions, testing framework and where tests live, and any directories or files Claude Code should not modify. Keep it under 500 words. A focused CLAUDE.md outperforms a comprehensive one. See what is CLAUDE.md for the full guide.
How do I know when to use plan mode vs. auto mode?
Use plan mode when the task touches more than 5 files, when it modifies production-critical logic, when you are unfamiliar with the codebase section being changed, or when the task is ambiguous enough that you want to review the interpretation before execution. Auto mode is appropriate for small, well-defined tasks on familiar codebases where the scope is clear.
How often should I use /compact during a session?
As often as context quality requires it. In practice, most sessions under 2 hours do not need /compact. Sessions running 3 or more hours benefit from /compact at the midpoint. The signal to use it: outputs start to feel less coherent, or Claude Code starts asking for context it was given earlier in the session.
Can I use Claude Code best practices in an enterprise environment?
Yes, with additional governance on top. Enterprise deployments add access controls, audit logging, and restricted MCP permissions to the practices above. See enterprise Claude Code for the governance layer that regulated teams and larger organizations need.
The practices are the product
The developers and teams that get consistent results from Claude Code are not using a different tool. They are using the same tool with a consistent, structured approach to every session.
CLAUDE.md before you start. Commit before you run. Plan before you execute on large changes. Read the diff before you accept. These four practices alone eliminate the majority of Claude Code frustrations.
Path one: implement practice 1 today. Open your current project. Write a CLAUDE.md file with your tech stack, your directory structure, your testing approach, and the directories Claude Code should not touch. That file alone improves every session you run from this point forward.
Path two: bring in Phos. Phos AI Labs works with engineering teams and business operators to implement Claude Code best practices at the team level, including CLAUDE.md templates, session protocols, and MCP integration setup. Thirty minutes, no deck. Start here.