Claude Code Best Practices That Actually Matter

Last updated: October 2026

Most best-practice lists for this tool are written by someone who set it up once, liked it, and wrote down what they did. These seven come from watching a professional set it up from nothing in September, run it hard and unsupervised across a weekend, and end up with both an impressive result and a bill he had not planned for. Every item below is either a habit that saved that engagement or the repair for something that cost it. Seven practices, in the order they start to matter, which is not the order most tutorials teach them.

In this post: one folder per project · skills scoped, not global · the 60% rule · reports and handoffs · how to hand it an error · permission modes · model and effort

1. One folder per project, opened as the project

The first thing this student said to me was that he did not know how to organise his files "in the back end" and that he was messy. He was not asking for a tool. He was asking for a filing system, and he was right to ask, because the filing system is the configuration.

So we started from an empty folder. One parent folder for all AI work, one subfolder per project, and that subfolder is what you open as your workspace. Not your home directory. Not your entire Documents folder. The project.

AI Projects/
  website-rebuild/      <- open THIS as the workspace
    .env                <- keys live here, never committed
    CLAUDE.md
    session-reports/
    session-handoffs/
  job-applications/
  client-proposals/

Two things follow from that, and they are the whole reason to bother. Reading files inside your working directory does not require approval, so the working directory is the real boundary of what the tool can see without asking you. Point it at one project and it reads one project. Point it at your Documents folder and it can read your tax returns while helping you with a landing page.

The second thing is quality. Everything in that folder is context the model can use, and everything outside it is context it has to guess at. A tight folder with your own notes and conventions in it produces better first drafts than a sprawling one, every time.

The fix: one folder per project, opened directly as the workspace. If you cannot say in one sentence what a folder is for, it is not a project folder yet.

2. Install skills into the project, not into your global setup

This is the item people argue with, so I will put the number first. When we ran the context check on this student's setup, he had 184 skills installed globally from earlier experiments. Every one of them was loading into every session he started, on every project, including the ones that had nothing to do with the work in front of him.

He pushed back, and his objection was reasonable: do I not want my tools available everywhere? No. A skill is not free to have. Its description sits in the context window from the moment the session opens, so a library you installed once out of curiosity is a tax you pay on every message for months afterwards. Multiply that by 184 and you have spent a meaningful slice of your window before you have typed anything.

So when we installed the ones he actually needed for the rebuild, we scoped them to that project only. Design and framework skills for the website work, a browser testing tool, a documentation lookup, an email sending integration. None of it global. The one he will need for his job application project can be installed in the job application project when he gets there.

There is a second reason to be selective that has nothing to do with context. A skill is a plain text file that gives instructions to a model with tool access, which means the risk is not a virus, it is instructions you did not read. Skills are text, so you can read one before you install it, or have Claude audit it for hidden instructions first. I go through the whole selection and audit process in loading Claude Code skills before you build anything.

The fix: install per project by default. Once a quarter, run the context check on a fresh session and delete anything global you have not deliberately used.

3. Stop at 60 to 70% of the context window

When we sat down for the second session, his session was at 85% of a one million token window. Roughly 852,000 tokens of conversation, most of it from a weekend of building. He had not noticed, because nothing tells you.

My rule is to write the session out and start fresh somewhere between 60 and 70%, and to never rely on automatic compaction to rescue a session that has gone past that. Compaction works, and it loses detail. The detail it loses is the detail you were relying on the model to remember, which is why the failure shows up as the model "getting worse" rather than as an error.

Where the session sits	What you will notice	What to do
Under 60%	Nothing	Keep working
60 to 70%	Still nothing	Write the report and handoff now, while it is cheap
70 to 80%	Slower replies, more usage burned per message	Stop adding new work, close it out
Above 80%	Quality slipping in ways you will blame on the model	Hand off, exit, start fresh

The part nobody connects is cost. A bloated session is not just a worse session, it is a more expensive one, because the whole conversation is re-read on every message you send. The student who was worried about hitting his usage limit every day was hitting it partly because he never closed a session.

The fix: run the context check at the start and the middle of every working session. Treat 70% as a hard stop, not a warning.

4. Reports and handoffs, with a README of the rules

Closing a session at 70% only works if closing it does not throw away what you learned. So the same prompt that fixes the context problem also fixes continuity.

What we had it build was small and boring and it changed how his projects ran:

session-reports/      one dated file per session, the full picture
session-handoffs/     one file per session, what the next one picks up
README.md             the rules both folders follow

The README is the part people skip and it is the part that makes this stick. It holds the naming convention, what belongs in a report versus a handoff, and the trigger for writing them. Without it you re-explain the format every time and the files drift into inconsistency within a fortnight. With it, you say "follow the README" and you are done.

Then the session-start habit, which has one non-obvious element. The prompt is not "read the handoffs". It is closer to: read the latest handoff and the last two reports, so that you understand where this project stands, and then in this session we are doing X. Telling it why it is reading something changes what it takes from the reading. People skip the why, get a shallow summary back, and conclude the technique does not work.

A handoff is also the only durable way to make a checkpoint survive. A decision you verified on Tuesday is only a verified decision on Thursday if it is written somewhere the next session reads. The mechanics of writing one Claude can actually debug from are in build a handoff file Claude can debug from.

The unglamorous half of what I do in 1-on-1 sessions is this: setting up the small files that make the next twenty sessions cheaper. Nobody books a lesson for it, and it is where most of the time comes back.

The fix: create both folders and the README in your next session, before you do any building. Ask for a report and a handoff every time you stop.

5. Hand it the error, the command, the environment, and what you already tried

This student could not get the tool to launch. We had already been through a path problem on the discovery call, so the obvious diagnosis was that the path was wrong again. It was not. His machine was blocking scripts from running under PowerShell's execution policy, which is a completely different failure wearing the same clothes.

What got us there in under two minutes was not expertise. It was the shape of the question. Screenshot the actual error with the snipping tool, then write a prompt containing four things: what you were trying to do, the exact command you ran, the environment you ran it in, and what you already tried. Paste the screenshot with it.

Compare the two versions of that request. "claude is not working, help" gets you a generic checklist starting with the path, which is where you already were. "I ran claude in a VS Code terminal on Windows, here is a screenshot of the error, the path fix from last week is still in place, and the command behaves differently in another terminal" gets you the execution policy on the first reply, because there is almost nothing else left it can be.

The general principle is that a model invents in proportion to how much it has to guess. Every specific you supply removes a branch it would otherwise have to fill in for itself. And the four items are always the same four, so this is a habit rather than a skill: what you did, the command, the environment, what you tried.

The fix: never paste an error on its own. Screenshot it, then add the command, the environment and your failed attempts before you hit enter.

6. Learn the permission modes before you need them

Cycling the permission mode takes one keystroke, and most people never learn what the options do. Which means they either sit in the safest one and find the tool exhausting, or sit in the loosest one and find out later what it did.

Mode	What it does	When it earns its place
Plan	Explores and reads, does not edit your files	A new project, a new feature, anything unfamiliar
Manual	Asks before every action	Someone else's repository, or anything you cannot afford to break
Auto	Asks for the consequential things, allows the rest	The working default, and the one I recommend
Accept edits	Stops asking about file edits for the rest of the session	A focused run where you are reading the diff anyway

Plan mode is the one worth knowing by name, because it is the answer to "I want to point this at something I care about without it touching anything". Anthropic's permissions documentation describes it plainly: "Claude reads files and runs read-only shell commands to explore but doesn't edit your source files." That is a real gate placed before the work starts, which is worth more than any amount of care applied afterwards.

The mode to be suspicious of is not in that table. It is the one that skips prompts entirely. People turn it on to stop the interruptions during one annoying task and then forget it is on for the next three weeks. If you have ever wondered how a careful person ends up with an incident, that is the mechanism, and it is a setting rather than a character flaw.

The fix: start new work in plan mode, live in auto, and check which mode you are in before any run you are not going to watch.

7. Match the model and the effort level to the job

Here is the weekend that taught me to say this out loud. He built for two days on the highest reasoning effort of the most capable model available to him, unsupervised, on the entry level subscription. He hit his usage limit, extra usage credits were switched on to carry him through, and by Monday the usage screen was reporting several times the monthly price of the plan he was on. The output was genuinely impressive: roughly a hundred pages migrated, and he was thrilled. He had also just found out what credits cost.

None of that was his mistake. He was following what he had been shown, which included the high effort setting and did not include the sentence that has to go with it. So here is the sentence: model choice and effort level are a dial you move during the day, not a setting you configure once.

Three rules cover most of it. Bulk building, file moving and routine edits run fine on the mid tier model, so reserve the expensive one for the decisions everything downstream depends on. When you are close to a usage limit, drop a tier rather than stopping. And if you are hitting your limit most days, the honest fix is the bigger plan rather than extra usage credits, because credits are the most expensive way to buy the same capacity. Switch them off so a long run cannot quietly reach for them. Whether the bigger plan is actually worth it comes down to how many days a week you get stopped, and that is a number you can have in a week.

What makes this hard is that the feedback is delayed. The cost of the wrong model shows up on Monday, attached to a result you were pleased with on Sunday, which is why almost nobody connects the two without being shown. I went through the rest of the surprises in 5 things Claude Code pricing does not tell you, including why your usage meter and your invoice are answering two different questions.

The fix: check your usage after any task that felt expensive, and calibrate the model to the next job rather than to your ambitions for the project.

Start here

If you only do one of these, do the third one. Open a session, run the context check, and look at the number. It takes ten seconds and it is the item that makes the other six visible, because a bloated session is simultaneously your quality problem, your cost problem and your continuity problem.

Run the context check on your current session and write down the percentage.
Ask for a session report and a handoff, plus a README holding the rules, then exit and start fresh.
In the fresh session, delete or rescope any global skills you cannot justify, and check which permission mode you are actually in.

That is twenty minutes, and it will change your next month more than any prompt technique will. Once those habits exist, put them somewhere the tool reads them automatically rather than relying on yourself to remember. A project instruction file is exactly that mechanism, and what goes in a CLAUDE.md file is the shortest version of the argument I have. If you would rather set it up once with someone watching, that is what a Discovery Call is for.

From the session logs of AI Tutor Code: 1-on-1 Python and AI tutoring for working professionals. The practices above come from real students and real builds, lightly anonymised.

Written by Michael Murr for AI Tutor Code: private 1-on-1 online tutoring for professionals learning Python, AI tools, Data Science, ML, and LLM engineering. 200+ students taught, 3,000+ hours delivered.