Write the one instruction file your AI reads first

Every time I start a Claude Code session, the first thing it reads is a single text file I wrote. It says who I am, how I like to work, where my files live, and the mistakes I don't want repeated. That file is called CLAUDE.md, and it's the reason I don't spend the first ten minutes of every chat re-explaining my business.

It's also the reason I learned something uncomfortable: an AI can read a rule and still not follow it. This guide covers both halves.

What the file is

CLAUDE.md is a plain text file that sits in a folder. When you open that folder in Claude Code, it reads the file before you type anything. Think of it as the briefing you'd give a new contractor on their first morning, except you only have to write it once.

You can have more than one. I keep one general file that applies to everything I do, and then smaller ones inside specific folders. The file in a client's folder holds rules for that client only. That way a rule about one client isn't sitting in the AI's head while it works on something unrelated.

Step 1: Create it

Open your top business folder in VS Code. Then either:

• Create a new file in that folder called CLAUDE.md, or
• Ask Claude Code to draft one for you by typing /init, then edit what it writes.

Either way, the file is yours to change. Rewrite anything that doesn't sound like your business.

Step 2: Write the five things it needs

Keep it short. Mine started as a page. Five sections cover most of what matters:

1. Who you are and what the business does. Two or three plain sentences. For example: "I run a two-person bookkeeping firm for restaurants. Most clients are owner-operators who hate paperwork."
2. How to work with you. "Be direct. Show me drafts before anything is sent. Ask one question at a time."
3. Where things live. Point at your folders and the map file from the previous guide. "Client files are in clients/. Read the client's brand folder before writing anything for them."
4. Hard rules. The things that must never happen. "Never email a client without my approval." "Never use the old logo."
5. Mistakes already made. A running list, added to every time the AI gets something wrong.

The last section is the one most people skip, and it's the most useful. When the AI does something wrong, don't just fix it in the chat. Add one line to the file so the next session knows. Over months, that list becomes a record of exactly how your business is different from the average one the AI assumes.

Step 3: Keep it a map, not a manual

The file is read every time, so everything in it takes up room in the AI's attention, whether it's relevant or not. Once mine grew long, I turned it into a router: short lines that say what exists and where the detail lives, with the detail in separate files.

A good test for each line: would the AI behave differently without it? If not, cut it.

Step 4: Know where written rules stop working

Here's what I learned the expensive way. A rule in CLAUDE.md is a reminder, not a lock. The AI reads it alongside everything else in the conversation and then decides what to do. Most of the time it follows the rule. Sometimes it doesn't, and nothing warns you.

I had a written instruction to check what a client had already told us before writing a list of interview questions. The rule was loaded and the AI still built the list from an old document, so it asked questions the client had already answered. Adding more words to the file would not have prevented that.

So I think about rules on a ladder, cheapest first:

1. Write it down. Costs nothing, works most of the time, fails silently.
2. Remind it at the right moment. Some tools let you show the AI a reminder exactly when a certain kind of request comes in, instead of only at the start.
3. Take the choice away. Instead of asking the AI to remember which questions are still open, keep one file of open questions and make that the only place a question list can come from.
4. Block it. A check that refuses to continue, like a publishing step that won't run on a post nobody approved.

The rule of thumb I use:

> If getting it wrong is expensive and it has already gone wrong once, move it up the ladder.

For most small businesses, steps 1 and 3 cover nearly everything. You don't need to be a developer for step 3. It's mostly about having one source for each thing instead of three.

Step 5: Ask the test question

Before you trust any rule, ask: what would have to be true for this to be broken without anyone noticing?

If the answer is "someone forgets" or "the AI skips it once", it's a reminder. That's fine for low-stakes rules. For anything involving money, clients or publishing, find a way to move it up the ladder, or keep a human check in the loop.

What to do next

Write a first version today. Ten minutes and five sections is enough to notice a difference in your next session. Then add a line every time the AI makes a mistake you don't want to see twice.

Next in this track:

• Give your AI a memory that lasts between chats, for the knowledge that's too big for one instruction file.
• Plan before the AI builds anything, so the rules get applied before the work starts, not after.

If you want a second pair of eyes on your instruction file or how your AI is set up, ask me for the free audit. I'll point out the rules most likely to be ignored and how to make them stick.