Claude Code Best Practices: 15 Habits That Help You Ship
· 5 min read · Guides
The best Claude Code habits come down to a few things. Plan before it writes code, keep project instructions short, make it prove its work, and clear your context often. Most of the rest is setup you do once.
Below are 15 habits, drawn mainly from Anthropic's own published guidance and what builders have written up publicly. I've left out anything I couldn't verify. If you haven't installed it yet, start with our Claude Code tutorial and come back.
Before you prompt: set the ground
1. Start with a CLAUDE.md, and keep it small
CLAUDE.md is a file Claude reads at the start of each session. Put your stack, how to run tests, and the conventions you care about in it. Anthropic's engineering post on agentic coding best practices says its own team treats these files like prompts and tunes them over time.
Short and specific beats long and vague. One public guide suggests staying under roughly 150 instructions. Treat that as a ceiling, not a target.
2. Add a rule every time Claude gets something wrong
Anthropic's power user tips recommend ending each correction by asking Claude to update CLAUDE.md so it doesn't repeat the mistake. It writes decent rules for itself. Read what it adds, though, and delete the fluff.
3. Check that your instructions actually loaded
If Claude ignores a rule, don't assume it's being stubborn. The memory docs say to run /context and check the memory files list. You may have the file in the wrong folder.
4. Use nested CLAUDE.md files for big repos
Keep the root file as a map and put narrow rules next to the code they apply to. Anthropic's write-up on large codebases describes this layered approach. Subdirectory files load as Claude moves through the tree.
5. Tighten permissions on purpose
Claude Code is conservative by default and asks before it acts. Use /permissions to allowlist the boring, safe commands (tests, linters) so you're not clicking approve forty times. Leave anything destructive on "ask". If you connect outside tools, read our MCP server setup guide first. Each server widens what Claude can touch.
While you work: the loop
6. Plan first, code second
The pattern Anthropic describes is explore, plan, code, commit. Press Shift+Tab to enter plan mode, or type /plan. Claude researches read-only and shows you an approach before it edits anything. Use it for any change that touches more than one file.
Here's a prompt you can paste:
Don't write code yet. Read the relevant files and propose a plan for: [feature].
List the files you'd change, any risks, and 2-3 questions you need answered.
Wait for my approval before editing.7. Let it ask you questions
The "2-3 questions" line in that prompt matters. Vague requests produce confident guesses. Questions up front are cheaper than a rewrite later.
8. Keep tasks small enough to review
One feature, one session, one reviewable diff. If you can't skim the change in a few minutes, the task was too big. Split it. This is also where the line between agentic work and pure vibes shows up. Our piece on agentic coding vs vibe coding covers it.
9. Commit before every risky step
Claude Code has /rewind, which reverts the conversation and code to an earlier checkpoint. Don't rely on it alone. A git commit is a restore point that survives everything. If git still feels fuzzy, git for beginners (AI edition) is the short version.
10. Abandon a bad session early
If you've corrected the same thing three times, stop arguing. Revert, write a sharper prompt, and start fresh. A cleaner start usually beats a long chain of patches.
Keeping it honest
11. Make it prove the change works
Anthropic's team has a simple move: ask Claude to prove it works, and have it compare behavior between your main branch and your feature branch. Tests are the other half. If a test exists first, Claude has something concrete to check against. Pair this with our simple routine for testing AI-written code.
12. Use a second Claude as reviewer
Anthropic's tips suggest having one Claude write a plan, then starting a second session to review it like a staff engineer. A fresh session hasn't bought into the first one's assumptions. It's a cheap way to catch drift.
13. Use hooks for rules that must never be skipped
CLAUDE.md asks. Hooks enforce. A hook is a script that runs at a set point, like before a tool call. A developer write-up on hooks and subagents notes that a pre-tool hook exiting with code 2 blocks the call, and Claude sees your error message. Good first hooks are blocking rm -rf, blocking edits to .env, and running tests when Claude finishes.
Test your hook by hand before trusting it. And hooks are a guardrail, not a security wall, so don't leave a long run unattended on that basis alone.
Context and cost
14. Clear context between tasks
Long sessions get muddy. Use /clear between unrelated tasks. For a long task, have Claude write its state to a file, clear, and start fresh by reading that file. DataCamp's guide calls this the Document & Clear pattern. It also suggests clearing around 60% context use, which is one author's rule of thumb, not an official number.
For heavy research, hand it to a subagent so the main session stays focused. Subagents are Markdown files in .claude/agents/.
15. Name sessions and save repeat work as commands
You can name a session upfront, for example claude --name "auth-refactor", so you can find it later. If you type the same prompt weekly, save it as a custom command. Anthropic's post shows commands living as Markdown files in .claude/commands/.
Which tool for which job
| You want… | Use |
|---|---|
| Claude to know your conventions | CLAUDE.md |
| A rule that can't be skipped | Hook |
| Research without cluttering the main session | Subagent |
| A repeatable prompt | Custom command or skill |
| A look before edits | Plan mode |
A starter CLAUDE.md
# Project
Next.js + Supabase. App code in src/, API routes in src/app/api/.
# Commands
- Test: npm test
- Lint: npm run lint
# Rules
- Never edit .env files.
- Run tests before saying a task is done.
- Ask before adding a dependency.Eight lines, and it already changes behavior. Grow it only when a mistake repeats. If you also use Cursor, the same instinct applies to writing Cursor rules.
Where to start tomorrow
Don't adopt all 15 at once. Pick three: a small CLAUDE.md, plan mode on multi-file changes, and a commit before each task. Add the rest when you feel the pain they solve.
Need something to practice on? Browse the daily app ideas, pick a small one, and run the loop above. When it's live, share what you built.
FAQ
What is the single most useful Claude Code habit?
Planning before coding. Plan mode or a "don't code yet" prompt costs a minute and stops Claude from building the wrong thing across ten files. Verification comes second: ask it to prove the change works.
How long should my CLAUDE.md be?
As short as you can get away with. Guides suggest staying well under a couple hundred instructions, but there's no official magic number. Put in only what Claude can't guess, and add a rule after a mistake repeats.
Do I need hooks and subagents as a beginner?
No. CLAUDE.md, plan mode, and frequent commits get you most of the value. Add a hook when there's a rule you keep having to repeat, and a subagent when research starts crowding your main session.
Cover photo: Avtar Singh on Unsplash
