# Claude Code best practices: 8 habits that work Almost every Claude Code habit comes from one limit. Its context window fills as it works, and it gets worse as it fills. So give it a test it can run, plan big changes before coding, name the files and the finish line, clear the conversation between tasks, and send research to subagents. - Page: https://tecyfy.com/coding-agents/claude-code/best-practices - Guide: Claude Code (https://tecyfy.com/coding-agents/claude-code), from Anthropic's documentation (https://code.claude.com/docs/en/overview) Anthropic's own guide to Claude Code starts from one fact: the [Context Window](https://tecyfy.com/concepts/context-window) fills up fast, and the model does worse as it fills. Every file read and every command output stays in it. A long debugging session can use tens of thousands of [tokens](https://tecyfy.com/concepts/token). Most of the habits below are ways to keep that window small and on topic, and the rest are ways to let the agent check its own work. ## 1. Give it a check it can run The agent stops when the work looks finished. If nothing can tell it otherwise, "looks finished" is all it has, and you become the test suite. So hand it something that passes or fails: a test, a build, a linter, a script that compares output with a known-good file, or a screenshot to match. Then it can do the work, run the check, read the failure and go again. Instead of: ```text make the price parser handle currencies ``` write: ```text parsePrice should accept "€12,50" and "$12.50" and return { amount: 12.5, currency }. add those 2 cases and "12.50" with no symbol to parse.test.ts, run the tests, and fix the code until they pass ``` Ask it to show the evidence, not to tell you it worked: the command it ran and what came back. ## 2. Explore, plan, then code Letting it write code straight away is how you get a tidy solution to the wrong problem. For anything larger than a small fix, split the work: 1. **Explore.** Press Shift+Tab until the status line shows plan mode, or start with `claude --permission-mode plan`. In plan mode it reads and answers but does not edit your files. 2. **Plan.** Ask for a plan: which files change, in what order, and how you will know it works. Press Ctrl+G to edit the plan in your own editor. 3. **Build.** Approve the plan and let it work against it, running the tests as it goes. 4. **Commit.** Ask it to commit with a message that explains why. Planning costs time too. If you could describe the change in one sentence, skip it. ## 3. Name the files, the limits and the finish line It can guess what you mean. It cannot read your mind. The fastest way to a right answer is a prompt that says: - **Where**: the file or folder, or `@src/billing/invoice.ts` to put the file straight into your message. - **What good looks like**: the behaviour, the edge case, the test that should pass. - **What to copy**: "follow the pattern in `ReportCard.tsx`" beats a description of your code style. - **What not to do**: "no new libraries", "don't change the public API". Vague prompts have their place. "What would you improve in this file?" is a good way to find what you did not think to ask. ## 4. Keep CLAUDE.md short [CLAUDE.md](/coding-agents/claude-code/project-instructions) is read at the start of every session, so every line costs room in every conversation. Keep only what it cannot work out by reading the code: the commands to build and test, rules that differ from the usual, branch and pull request habits, and the traps in your setup. For each line, ask whether removing it would cause a mistake. If not, cut it. A rule it keeps breaking is usually a rule lost in a file that is too long. Things that must happen every time belong in [hooks](/coding-agents/claude-code/hooks), which run whatever the model decides. ## 5. Clear between tasks, and start again after 2 corrections The most common bad session is the kitchen sink: one task, then an unrelated question, then back to the first task, with all of it still in the window. Type `/clear` when you move to something unrelated. The second is correcting the same mistake over and over. Each failed attempt stays in the conversation and pulls the next one off course. After 2 corrections on the same problem, clear and write one better first message that says what you have learned. A clean start with a good prompt usually beats a long session full of wrong turns. ## 6. Send research to a subagent Asking it to "look into" something unscoped is how it ends up reading hundreds of files into your window. Either scope the question tightly or hand it off: ```text use a subagent to find every place we read the session token, and report the files and line numbers ``` A [subagent](/coding-agents/claude-code/subagents) reads in its own context window and returns only a summary, so your main conversation keeps its room for the actual change. ## 7. Let it interview you for big features For a feature with many open questions, do not write the spec yourself first. Ask it to interview you: about the edge cases, the interface, the trade-offs. Have it write the result to a spec file, then start a fresh session to build from that file. The building session starts clean, with a written plan instead of a long conversation. ## 8. Review with fresh eyes A session that just wrote code is inclined to like it. For a real review, open a second session that did not write it: ```text review the changes on this branch for race conditions and missing error handling. say what you would block a merge on ``` Then take the findings back to the first session. The same trick works for tests: one session writes the tests, another writes the code that passes them. ## The undo button is not Git You can rewind any session with Esc twice, which restores files its edit tools changed. It does not undo shell commands, database writes or anything pushed to a server. Commit working states as you go, and keep the permission mode tight enough that the things you cannot undo still ask you first. [Permissions](/coding-agents/claude-code/permissions) covers how. ## Questions ### What is the single most useful Claude Code habit? Give it a check it can run - a test, a build, a linter or a screenshot to compare against. With a check it can work, test, read the failure and try again until it passes. Without one, it stops when the work looks done, and you have to find the mistakes. ### When should I use plan mode? When you are unsure of the approach, when the change touches several files, or when you do not know the code well. For a change you could describe in one sentence, such as a rename or a typo, skip the plan and ask for it directly. ### Why does Claude Code ignore rules in my CLAUDE.md? Usually because the file is too long and the rule is lost among the others. Cut every line it would follow anyway, keep what it cannot work out from the code, and turn rules that must never be broken into hooks. ### How many times should I correct Claude Code before starting again? Anthropic's own advice is 2. After 2 failed corrections on the same problem, the conversation is full of wrong attempts. Run /clear and write one better first message that includes what you learned. ## Sources - [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices) - [Choose a permission mode](https://code.claude.com/docs/en/permission-modes) - [Checkpointing](https://code.claude.com/docs/en/checkpointing)