How to Use Claude Code Well: The Habits That Actually Matter

What this covers

This is about operating Claude Code once it is installed and you have run a first task — the working practice rather than the introduction. If you are earlier than that and still want to know what the thing is and what a first real task looks like, the beginners guide linked at the end is the better starting point.

Everything below applies whether you use it in a terminal, the desktop application, or an editor extension. The interface changes; the working habits do not.

The one constraint everything follows from

Claude Code holds your entire session in a context window: every message, every file it reads, every command output. That space is finite, and it fills much faster than people expect — a single debugging session or a wander through an unfamiliar codebase can consume tens of thousands of tokens on its own.

The part that matters is what happens as it fills. Performance degrades. Claude starts losing track of instructions you gave earlier, and mistakes become more frequent. It does not announce this. The session just gets quietly worse, and the natural response — explaining again, correcting again — makes it worse still, because each correction consumes more of the space that was already short.

Once you see that, most of the advice in this post stops being a list of tips and becomes obvious. Keep sessions focused. Push exploration somewhere else. Reset between unrelated tasks. Give Claude a way to check its own work so it is not spending your context asking you. These are all the same idea wearing different clothes.

If you would rather have this built for you than build it yourself, an AI consultation is where we scope that.

Explore, plan, implement, verify

The single biggest improvement most people can make is to stop asking for the change first. Letting Claude jump straight to code is how you end up with a competent solution to the wrong problem.

Plan mode exists for this. Press Shift+Tab until the status bar shows plan mode is on, and Claude will read files and answer questions without changing anything. Ask it to understand the area first — how sessions are handled, where a value comes from, what the existing pattern looks like — and only then ask for a plan.

Read the plan properly. This is the cheapest possible moment to catch a wrong assumption; correcting one here costs a sentence, and correcting the same assumption after implementation costs a rewrite. If the plan needs real editing rather than a comment, Ctrl+G opens it in your text editor.

Then switch out of plan mode and let it build against the plan it just wrote.

One honest caveat: planning has overhead and is not always worth it. If you could describe the change in one sentence — rename this, add a log line, fix this typo — just ask for it. Planning earns its cost when the change touches several files, when you are unsure of the approach, or when you do not know the code well.

Give it something it can check itself

This single habit does more than anything else here, and it is the difference between a session you have to watch and one you can walk away from.

Claude stops when the work looks done. If nothing can tell it otherwise, looks-done is the only signal available — and you become the verification step, which means every mistake waits for you to notice it. Give it something that returns a pass or a fail and the loop closes on its own: it does the work, runs the check, reads the result, and keeps going until the check passes.

The check can be almost anything that produces a readable signal. A test suite. A build that exits non-zero. A linter. A script that compares output against a known-good fixture. A screenshot compared to a design.

The practical version is to put it in the same sentence as the request. Instead of asking for a function that validates email addresses, ask for the function, give three example cases and their expected results, and tell it to run the tests after implementing. Instead of reporting that the build is failing, paste the error, ask for the root cause rather than a suppression, and ask it to confirm the build succeeds afterwards.

Then ask for the evidence rather than the assertion — the test output, the command it ran and what came back. Reading evidence is faster than re-running the check yourself, and it is the only thing that works for a session you were not watching.

Keeping the context window clean

Four habits, roughly in order of how often you will want them.

• Clear between unrelated tasks. The /clear command resets the context window entirely. Use it far more often than feels necessary — moving from a bug fix to a documentation change with the bug fix still loaded is pure cost.
• Delegate exploration to subagents. Ask it to use subagents to investigate something and the reading happens in a separate context window; only the summary comes back. Since research is what fills context fastest, this is one of the most useful things available to you.
• Compact deliberately when a long session is genuinely one piece of work. Compaction happens automatically near the limit, but /compact with an instruction — telling it what to preserve — keeps the parts you care about.
• Ask throwaway questions with /btw. The answer never enters the conversation history, so you can check a detail without paying for it later.

Course-correcting without wrecking the session

Interrupt early. Escape stops Claude mid-action and preserves the context, so you can redirect rather than start over. Watching a wrong approach run to completion out of politeness helps nobody.

Pressing Escape twice, or running /rewind, opens the rewind menu — every prompt you send creates a checkpoint, and you can restore the conversation, the code, or both. This changes how you can work: rather than planning every move carefully, you can tell Claude to try the risky thing, and rewind if it does not pan out.

One important limit. Checkpoints only capture changes Claude made through its own file-editing tools. Anything done through a shell command or an external process is not covered. It is a convenience, not a substitute for version control, and treating it as one will eventually cost you.

The rule worth internalising: if you have corrected the same thing twice in one session, stop correcting. The context is now full of failed attempts, and each new correction competes with them. Clear it and start again with a better prompt that includes what you just learned. A clean session with a sharper prompt beats a long session carrying its own history of mistakes, almost every time.

CLAUDE.md, and why a long one backfires

CLAUDE.md is a file Claude reads at the start of every conversation. It is where persistent project context lives — the commands it could not guess, the style rules that differ from the defaults, the environment quirks, the gotchas. Run /init to generate a starter from your project, then refine it as you go, and /context to confirm it actually loaded.

The counter-intuitive part, and the mistake almost everyone makes: a longer file works worse. Because it loads every session, everything in it competes for attention with everything else. Past a certain length, important rules get lost in the noise and Claude starts ignoring instructions you thought were binding.

So the test for every line is simple — would removing this cause a mistake? If not, cut it. Leave out anything Claude can work out by reading the code, standard conventions it already knows, and anything that changes often. And if it keeps ignoring one particular rule despite the rule being right there, the usual cause is not that the rule needs more emphasis; it is that the file is too long and the rule is drowning.

Emphasis works, but only if it is rare. Marking one line as important makes it stand out. Marking ten means none of them do.

For knowledge that only matters sometimes, use a skill instead — those load on demand rather than sitting in every conversation.

The commands worth knowing

There are many. These are the ones that come up constantly.

• Starting: claude opens an interactive session; claude followed by a quoted task starts one with that prompt already in; claude -p runs a single query and exits, which is what you use in scripts and pipelines.
• Returning: claude -c continues the most recent conversation in that directory, and claude -r lets you pick from a list. Sessions persist, so a task spanning several sittings does not need re-explaining.
• During a session: /clear to reset, /compact to condense, /rewind to go back, /help to see what is available. Typing a single slash lists the commands and skills you have.
• Shift+Tab cycles the permission mode, which is how you enter and leave plan mode.
• Referencing things: @ points at a file and Claude reads it before answering. You can paste images directly, give it URLs, or pipe data straight in with something like cat error.log piped into claude.
• Permissions: /permissions pre-approves tools you trust so you are not clicking through approvals, and /sandbox restricts what a command can reach rather than asking about each one.

The five ways sessions go wrong

These are common enough to have names, and recognising one as it happens saves a lot of time.

• The kitchen sink session. You start on one task, ask something unrelated, then return to the first. Context is now full of things that do not apply. Clear between unrelated tasks.
• Correcting over and over. Two failed corrections means the context is polluted with failed approaches. Clear and rewrite the prompt rather than correcting a third time.
• The over-specified CLAUDE.md. Too long, so half of it is ignored. Prune ruthlessly, and convert anything that must always happen into a hook, which is enforced rather than advisory.
• The trust-then-verify gap. A plausible-looking implementation that does not handle the edge cases. If you cannot verify it, do not ship it.
• Infinite exploration. Asking it to investigate something unscoped, and watching it read hundreds of files. Scope the question, or push it to a subagent so the reading does not land in your context.

Where this stops being a laptop tool

Everything above assumes a person driving a session and reviewing the result. That covers most of what Claude Code is for, and for a lot of people it is the whole story.

There is a threshold worth watching for, though. Once you are running it non-interactively in a script, fanning work across many parallel invocations, or wiring it into a pipeline that runs without anyone watching, you have moved from using a tool to operating a system — and the questions change. What happens when a run fails at three in the morning. Who notices. What it is allowed to touch. Whether the output is checked by anything other than the thing that produced it.

None of that is an argument against automating it. It is an argument for noticing when you have crossed the line, because the failure mode is a script that worked reliably for two months, quietly stopped, and was not missed until something downstream broke.

Common questions

How do I know if my context is getting full? Run /context to see what is loaded. In practice you will often feel it before you check it — repeated instructions being forgotten, or mistakes on things that were fine earlier, are the usual tell.

Should I always use plan mode? No. It has real overhead and is wasted on small, clearly-scoped changes. Use it when the change spans several files, when you are unsure of the approach, or when you do not know the code. If you can describe the diff in one sentence, skip it.

What is the difference between /clear and /compact? Clear throws the conversation away and starts fresh, which is what you want between unrelated tasks. Compact condenses it while keeping what matters, which is what you want when a long session is genuinely one continuous piece of work.

Can I undo something it did? Yes, several ways. Ask it to undo the change, or press Escape twice to open the rewind menu and restore the conversation, the code, or both. The caveat is that checkpoints only cover changes made through its own editing tools — anything done via a shell command is not tracked, so version control still matters.

Why does it keep ignoring my CLAUDE.md rule? Almost always because the file is too long. Everything in it competes for attention, and past a certain size the important rules get lost. Cut it back rather than adding emphasis.

Do I have to approve every action? That depends on your plan and settings. Some sessions start in a mode where a classifier reviews actions instead of you; others ask before each change. Shift+Tab switches modes, and /permissions lets you pre-approve specific tools you trust so the routine ones stop interrupting.

What is the fastest way to get better at it? Give it a way to verify its own work, and clear context more often than feels necessary. Those two habits account for most of the difference between people who find it transformative and people who find it frustrating.