Claude Code Best Practices: Habits That Get Better Results
12 min read
When a Claude Code session goes badly, the cause is almost always one of two things. Claude built something different from what you had in mind, or it said "done" while the work was not. Neither one is a weakness of the tool. Both come from information Claude did not have.
Tell Claude what it cannot see, and give it a way to check its own work.
The habits below are the ones that matter most, in the order you will use them. They assume you have already installed Claude Code and run a session. If not, start with Claude Code for Beginners.
How a good session runs
Claude Code works in a loop: it gathers context, takes action and verifies the result. You sit in that loop too. You can interrupt at any time to steer it. Every habit in this guide improves one part of the loop.
Habit 1: Tell Claude only what it cannot see
Claude starts every task by reading your code, and it does that well. It finds your folder layout, your test framework and the way existing components are built, usually faster than you could explain them. That means most of what you are tempted to write down is already known.
What it cannot find is information that was never in the repo: a decision from a meeting, a deploy process that lives in one person's head, the environment variable your integration tests need. Ask two questions before you add a line to a prompt or to CLAUDE.md:
- Could Claude find this by reading the code?
- Would it actually go and look?
If both answers are yes, leave it out. Long lists of obvious facts bury the one fact that matters. The next guide, CLAUDE.md Explained, covers where the lasting ones go.
Habit 2: Write a specific prompt
A specific prompt works for the same reason: it gives Claude information it does not have. Name the file or area, describe the symptom, and say what fixed looks like. If you prefer one of two reasonable approaches, say which, because Claude cannot read that from the code.
| Instead of | Try |
|---|---|
fix the login bug | users report login fails after the session times out. look at token refresh in src/auth/, write a failing test that reproduces it, then fix it |
add a calendar widget | follow the pattern in HotDogWidget.php and build a calendar widget that lets you pick a month and page between years. no new libraries |
clean up this file | split utils.ts into one file per concern. keep every export name the same so no import breaks |
The better prompts name the place, the proof and the limits. They are not longer for the sake of it. Each added phrase removes a guess.
Checkout fails for users with an expired card. The relevant code is in src/payments/. Investigate first and tell me what you find. Do not change anything until I say so.
”Notice the delegation in that prompt. You give context and direction, then let Claude work out which files to read and which commands to run.
Magic words do not exist
Phrases like "think step by step" or "be thorough" are ordinary prompt text, not switches. How hard Claude thinks is set by the effort level, which you change with the model settings, not by wording.
Habit 3: Hand over the thing instead of describing it
If you already have what Claude needs, give it directly. Typing a description of an error is slower and less accurate than the error itself.
- 1
Reference a file with @
Type
@and the path, such as@src/auth/session.ts, to put that file's contents in your message. - 2
Paste an image
Paste a screenshot of the design you want or of the error you see. Claude reads images.
- 3
Pipe in command output
Send output straight from your shell, for example
cat error.log | claude -p "what's going on here".
Habit 4: Let Claude interview you when you are not sure
You do not have to work out the whole plan before you prompt. When an idea is still fuzzy, ask Claude to question you until it can write the spec:
I want to add rate limiting to the public API but have not thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.
”Claude comes back with questions about the parts you have not pinned down: per user or per key, what happens to requests over the limit, what is out of scope. When the answers add up, it writes SPEC.md. Start a fresh session to build from that file, so the build begins with a clean context and a written definition of done.
For anything with real risk, add the plan step from the permissions guide. Claude Code Permission Modes and Plan Mode, Explained shows how to make Claude explore and propose before it edits.
Habit 5: Give Claude a check to run
This is the habit with the biggest effect. Claude stops when the work looks done. If it has nothing to run that tells it whether the work is actually done, "looks done" is all it has. In practice you become the test suite, and every mistake waits for you to notice it.
Give it something that comes back pass or fail, and Claude can close the loop on its own: it makes the change, runs the check, reads the failure, fixes it and runs the check again.
The check can be nearly anything Claude can read the result of:
- a test file
- a build's exit code
- a linter or type check
- a script that compares output to a saved example
- a browser screenshot placed next to the mockup
If your project already has one, the most useful line in your CLAUDE.md is the command that runs it. How strict you make the check is up to you:
| Level | How | Good for |
|---|---|---|
| In the prompt | run the auth tests after, and keep going until they pass | Any task, no setup |
| As a goal | /goal all tests in tests/auth pass and lint is clean sets a condition that a separate model checks after every turn | Long runs nobody watches |
| As a Stop hook | A script that runs when Claude tries to finish and sends it back to work if it fails | A rule that must always hold |
| By a fresh reviewer | /code-review checks the diff in a new subagent that never saw your conversation | A second opinion |
The one check to start with
Add the exact test command to CLAUDE.md, then end your prompts with "run it and show me the output". That alone fixes most "it said it was done" problems.
Habit 6: Ask for evidence, not reassurance
"All tests pass" on its own tells you very little. Ask Claude to show the command it ran and the output, or the screenshot. Reading the output is faster than running the check yourself, and for a session you were not watching it is the only proof you have.
Once Claude says it is done, you can also run /verify, which has Claude build and run the app and look at the result. That catches the kind of problem tests and type checks miss, such as a page that technically loads but is visibly broken.
Inside Claude Tutorial
Checking the work is part of the skill
Knowing what to verify and asking for proof applies to every kind of Claude work, and the app practices it with real tasks, not only code.
Habit 7: Watch the first minute and steer early
No setup replaces watching the start of a task and stepping in when Claude heads somewhere you did not intend. Learn these controls by heart:
Escstops Claude mid-action and keeps everything up to that point, so you can redirect without losing work.- Type and press Enter while Claude works to queue a correction. Claude reads it as soon as its current tool calls finish and adjusts.
/rewind, orEsctwice on an empty prompt, opens a menu where you roll the code, the conversation or both back to an earlier point. That makes it low-risk to try the bolder approach first./btwasks a quick side question without adding it to the conversation history.
Rewind covers files Claude edited, not everything
Files changed only by a shell command are not restored, and neither are databases or deployments. Rewind works alongside git. It does not replace it.
Habit 8: After two failed corrections, start over
If you have corrected the same thing twice and it is still wrong, a third correction adds to a conversation that already contains two failed attempts for Claude to keep rereading. Run /clear and write one new prompt that includes what you learned.
It feels like losing progress. It almost always works better. /clear between unrelated tasks is also a good habit on its own, because a focused context gives better answers and costs less.
For work that spans several days, name the session with /rename oauth-migration, then pick it up later with claude --resume oauth-migration. claude --continue resumes the most recent one.
Habit 9: Keep rules short, and move hard rules out of prose
Everything you tell Claude in a prompt or in CLAUDE.md is a request the model reads and usually follows. A hook, a deny rule or a managed setting is different: Claude Code enforces it every time, whatever the model decides.
Use the first kind for almost everything, because Claude is good at judging when a guideline fits. Use the second kind for the few rules that cannot have exceptions, such as "never edit the generated client" or "always run the formatter after creating a file".
A signal worth noticing
If you keep adding emphasis to a CLAUDE.md line and Claude still misses it, the line belongs in a hook. The reverse also holds: if you built hooks for things that are only preferences, delete them.
If your session gets long, check /context to see what is using space. Claude compacts the conversation automatically, and a summary can lose detailed instructions from early on. Persistent rules belong in CLAUDE.md, which is read again from disk after /compact. You can also guide the summary: /compact focus on the API changes.
Advice you can stop following
Some older tips were workarounds for things earlier models could not do. Current models have caught up, and the workarounds now cost more than they give.
| Old advice | Why you can drop it |
|---|---|
| Manage the context window aggressively | Most current models have a very large window and compaction is automatic. /clear between tasks is still worth it. |
| Add IMPORTANT or ALL CAPS to rules | Plain wording is followed, and emphasis makes Claude over-apply the rule. A rule that cannot bend is a hook. |
| Say "think hard" or "be thorough" | Effort is the real control. These phrases only nudge within it. |
| Tell Claude to keep going and not be lazy | Models carry on through an agreed task. Giving Claude a check to pass is different, and still worth doing. |
| Describe your architecture in CLAUDE.md | Claude reads the repo. Write only what it cannot find. |
| Use a subagent to get a better answer | Delegating the same task does not improve it. A fresh reviewer helps because it has not seen your reasoning, and that is a different thing. |
Frequently asked questions
How do I get better results from Claude Code?
Give it information it cannot see, write specific prompts, hand over files and errors instead of describing them, and give it a check that passes or fails. Then steer early with Esc, and run /clear when corrections are not working.
Why does Claude Code say it is done when it is not?
It stops when the work looks done. If nothing it can run proves otherwise, "looks done" is all it has. Give it a test, build or linter to run, and ask it to show the output.
Should I use plan mode every time?
No. Use it when a change touches many files, when you do not understand the code yet, or when a mistake would be costly. For a one-sentence change, ask for it directly.
When should I use /clear?
Between unrelated tasks, and after two failed corrections of the same problem. Start the new prompt with what you learned.
What is the difference between CLAUDE.md and a hook?
CLAUDE.md is instructions Claude reads and usually follows. A hook is a script Claude Code runs at a fixed point, so it happens regardless of what the model decides. Use a hook for a rule with no exceptions.
How do I resume yesterday's Claude Code session?
Run claude --continue for the most recent conversation, or claude --resume to choose one. If you named a session with /rename, use claude --resume <name>.
Your habits checklist
Your prompt names the place, the symptom or goal, and what done looks like
Claude has a command it can run that comes back pass or fail, and you asked to see its output
You watched the first minute and know
Esc,/rewindand/clearCLAUDE.md holds only what Claude cannot find in the code, and rules that must never bend are hooks
You read the diff before committing, as you would a colleague's pull request
Continue reading
- Claude Code for Beginners: Install, Sign In and Run Your First Task to set up and run your first session.
- CLAUDE.md Explained: Teach Claude Code Your Project Once for the file that carries your rules between sessions.
- Claude Code Permission Modes and Plan Mode, Explained for choosing how much Claude may do without asking.
- What to Do When Claude Won't Do What You Asked for the same problem in the chat app.
- How to Make Multi-File Changes With Claude Code for these habits applied to a change across many files.