Claude Code Best Practices: 20 Tips That Actually Work
Claude Code best practices and tips from the official guide and daily use: verification loops, plan mode, lean CLAUDE.md, context hygiene and parallel work.
By Claudekit Team Published 11 min read
Claude Code rewards a few habits far more than any clever prompt. This guide collects the ones that make the biggest difference, drawn from Anthropic’s official best-practices guide (checked October 24, 2026) and from daily use, and groups them by when you need them.
New to the tool? Start with Getting started with Claude Code or our hands-on Claude Code tutorial, then come back here.
The one constraint behind every tip
Almost every best practice follows from one fact: Claude’s context window fills up fast, and performance degrades as it fills. Every message, every file Claude reads and every command output lands in context. A single debugging session can consume tens of thousands of tokens, and when context gets crowded, Claude starts forgetting earlier instructions and making more mistakes.
Treat context as your scarcest resource and most of the tips below become obvious.
Tips for every task
1. Give Claude a way to verify its work
This is the highest-leverage habit. Without a check, “looks done” is Claude’s only stopping signal, and you become the test suite.
| Instead of | Say |
|---|---|
| “implement email validation” | “write validateEmail; user@example.com is valid, user@.com is not; write tests and run them” |
| “make the dashboard look better” | “[screenshot] implement this design, screenshot the result, list differences and fix them” |
| “the build is failing” | “the build fails with [error]; fix the root cause and confirm the build passes” |
Ask for evidence, not assertions: the test output, the command and its result, or a screenshot. For unattended runs, turn the check into a Stop hook or a /goal condition so the session can’t end until it passes.
2. Explore, plan, implement, commit
Use plan mode (Shift+Tab until it shows “plan mode on”, or claude --permission-mode plan) to separate research from editing:
- Explore: “read src/auth and explain how sessions work.”
- Plan: “I want to add Google OAuth. Which files change? Write a plan.” Press
Ctrl+Gto edit the plan in your editor. - Implement: approve the plan; ask Claude to write tests and run them.
- Commit: “commit with a descriptive message and open a PR.”
3. Skip the plan for one-sentence changes
Planning has overhead. If you can describe the diff in one sentence (a typo, a log line, a rename), just ask for it.
4. Be specific about scope, sources and patterns
- Scope: “write a test for foo.py covering the logged-out edge case; avoid mocks.”
- Sources: “look through ExecutionFactory’s git history and summarise how its API evolved.”
- Patterns: “follow how HotDogWidget.php is built to add a calendar widget.”
- Symptoms: “login fails after session timeout; check token refresh in src/auth; write a failing test first.”
5. Feed it rich context directly
Reference files with @path, paste screenshots, give documentation URLs, or pipe data in: cat error.log | claude -p "explain this error". Letting Claude fetch context itself with Bash or MCP tools also works.
Tips for your setup
6. Keep CLAUDE.md short and specific
Run /init to generate a starter, then prune hard. For every line ask: would removing this cause Claude to make mistakes?
| Include | Leave out |
|---|---|
| Commands Claude can’t guess | Anything it can learn by reading code |
| Non-default style rules | Standard language conventions |
| Test runners and how to run one test | Detailed API docs (link instead) |
| Branch and PR conventions | Information that changes often |
| Project-specific architecture decisions | File-by-file descriptions |
| Environment quirks and gotchas | “Write clean code” |
If Claude keeps ignoring a rule, the file is probably too long. Our CLAUDE.md guide has templates for five stacks.
7. Move occasional knowledge into skills
CLAUDE.md loads every session. Procedures you need sometimes (releases, migrations, API conventions) belong in skills, which load only when relevant or when you run /skill-name. Use disable-model-invocation: true for skills with side effects so they run only when you call them.
8. Turn must-happen rules into hooks
CLAUDE.md is advisory; hooks are deterministic. “Run the formatter after every edit” or “never write to migrations/” should be hooks. Claude can write them for you: “write a hook that runs eslint after every file edit.”
9. Reduce prompts without losing control
Auto mode is the built-in starting mode for interactive terminal and VS Code sessions from v2.1.283: a classifier approves routine actions and blocks risky ones. In Manual mode, pre-approve safe commands with /permissions and enable /sandbox for OS-level isolation. The permission modes guide explains each mode.
10. Prefer CLIs, then MCP
CLI tools such as gh, aws and gcloud are the most context-efficient way to reach external services. Use MCP servers for tools without a good CLI; see best MCP servers for vetted picks, and disable servers you aren’t using.
11. Install a code intelligence plugin for typed languages
The official docs recommend code intelligence plugins for precise symbol navigation and automatic error detection after edits. Browse with /plugin; the plugins guide explains installation and trust.
Tips for managing a session
12. Course-correct early
Escstops Claude mid-action and keeps context.Esctwice or/rewindrestores conversation, code or both to a checkpoint.- “Undo that” asks Claude to revert its own change.
Checkpoints only cover edits made with Claude’s file tools, not Bash side effects, so commit often.
13. Two failed corrections means start over
If you’ve corrected Claude twice on the same issue, the context is full of failed attempts. Run /clear and write a better first prompt that includes what you learned. A fresh session with a sharper prompt almost always wins.
14. Clear between tasks, compact with intent
/clearbetween unrelated tasks./compact Focus on the API changesto summarise with a focus.- In the rewind menu, Summarize from here or Summarize up to here condenses part of the conversation.
/btwanswers a side question without adding it to history.
Our context management guide shows how to read /context and when to use each.
15. Send investigations to subagents
“Use subagents to investigate how token refresh works and whether we have OAuth utilities to reuse.” Subagents read files in their own context and report a summary, keeping your main session clean. See the subagents guide.
16. Name sessions and resume them
Use /rename oauth-migration, then claude --continue or claude --resume to pick up later. Treat sessions like branches: one workstream each.
Tips for bigger work
17. Let Claude interview you before big features
Start with: “I want to build [feature]. Interview me in detail using the AskUserQuestion tool about implementation, UI/UX, edge cases and tradeoffs, then write a complete spec to SPEC.md.” Then implement the spec in a fresh session with clean context.
18. Add an independent review step
Before calling work done, run /code-review or ask a subagent to check the diff against your plan. Tell the reviewer to report only gaps that affect correctness or requirements, or you’ll chase style nitpicks. Our code review prompt is a good starting point.
19. Parallelise with worktrees
Run separate sessions in isolated git checkouts so edits don’t collide, or use a writer/reviewer pair: one session implements, a second reviews with fresh eyes. The worktrees guide covers setup.
20. Script repetitive work with headless mode
For migrations and audits, loop over files with claude -p:
for file in $(cat files.txt); do
claude -p "Migrate $file to the new logger API. Return OK or FAIL." \
--allowedTools "Edit,Bash(git commit *)" \
--permission-mode dontAsk
doneTest on two or three files first, refine the prompt, then run the rest. /batch does a similar fan-out with subagents in worktrees. More in the headless mode guide.
Five failure patterns to recognise
| Pattern | Fix |
|---|---|
| Kitchen-sink session: unrelated tasks in one context | /clear between tasks |
| Correcting the same mistake again and again | /clear after two failures; rewrite the prompt |
| Over-long CLAUDE.md that Claude half-ignores | Prune; convert must-follow rules to hooks |
| Plausible code that misses edge cases | Always give a verification step |
| Unscoped “investigate this” that reads hundreds of files | Scope it, or use a subagent |
Keep the habits, then build your kit
These habits matter more than any single tool. Once they’re second nature, package what works (skills, hooks, subagents, MCP config) into a reusable setup; our What is a Claude kit? guide and Claude kit hub show how. Watching spend too? The Claude Code pricing guide explains how each habit saves tokens.
Frequently asked questions
What is the single most important Claude Code best practice?
Give Claude a way to verify its work: a test, a build, a linter or a screenshot to compare. With a pass/fail signal Claude iterates until the check passes instead of stopping when the work merely looks done. Anthropic's own best-practices guide puts this first.
How long should CLAUDE.md be?
As short as possible. For each line, ask whether removing it would cause mistakes; if not, cut it. Put commands Claude can't guess, non-default conventions and gotchas in it, and move occasional procedures into skills, which load only when needed.
When should I use plan mode?
When you're unsure of the approach, the change touches several files, or you don't know the code well. Skip it for changes you could describe in one sentence, such as a typo fix or a renamed variable.
Why does Claude Code get worse in long sessions?
The context window fills with file contents, command output and earlier attempts, and performance degrades as it fills. Use /clear between unrelated tasks, /compact with focus instructions, /btw for side questions, and subagents for investigations.