What a system instructions file
actually does.

Start a new chat and Claude has whatever it happens to have picked up about you, which is a different thing from what you actually want it to know. Talk to it for an hour, close the tab, open a new one, and the important part of that hour is usually gone.

There are two ways things carry over, and the difference matters. Claude Code writes its own notes between sessions, on by default, and that is genuinely useful. It is also Claude deciding what was worth remembering. A system instructions file is the other one: one specific file, usually called CLAUDE.md, that you write, that you can read back, and that gets loaded at the start of every single session before you type a word. Notes are what it inferred. This file is what you decided.

Why it matters

Sofia runs a wedding planning business. Every proposal needs the same three things: her pricing, her tone with clients, and one rule she never breaks: never confirm a date as booked until the deposit has actually cleared.

Without the file, she explains all of that fresh, every single chat. One session, she didn’t. A client asked if their date was locked in. Claude said yes, days before the deposit had even arrived. Nobody told it not to say that, so it guessed, confidently, in her voice, to a client waiting on a real answer.

With the file, she doesn’t explain any of it anymore. New chat, and the rules are already there.

What to avoid

Two mistakes are common, and both feel like they should help.

Too many rules. Writing down everything feels safer. In practice, a long file makes Claude worse at following any single instruction, not better. Anthropic’s own current guidance for Claude Code keeps these files short, under roughly 200 lines, because a longer file eats into how much attention any one instruction gets.

A stale file. Sofia’s still says “no weekend availability,” months after she started taking weekend bookings. Nobody updated it. Now every proposal quietly assumes something false. A system instructions file isn’t something you write once and forget. It only stays useful if you update it when something changes.

TL;DR

• Your AI reads this before it reads your first prompt. It isn’t the notes it keeps on its own, it’s the set of rules you decided, in your words.
• Keep it short, under 200 lines if possible. A long list of rules becomes harder to follow. Just ask any kid.
• Write what’s always true, not what’s only true at this moment. Update it the second something changes. A stale rule is worse than no rule.

Here’s what she actually wrote, once, and hasn’t had to repeat since.

# Sofia's Wedding Planning. Working rules.

## Who I am
Solo wedding and event planner. Every proposal and email should sound like me: warm,
direct, no corporate stiffness.

## Pricing
- Full planning: from EUR 3,200
- Day-of coordination: from EUR 950
- Never quote a price without knowing headcount and venue first.

## The rule that matters most
Never confirm a date as booked until the deposit has actually cleared. If asked
whether a date is locked in, the honest answer before the deposit clears is "pending
deposit," not "yes."

## Tone with clients
Warm, not gushing. No exclamation marks. Couples are often stressed, keep it calm and
clear.

## Proposal format
Every proposal: package summary, three deliverables, next step. Nothing longer than
one page.

A few lines here are doing more work than they look like.

“Never quote a price without knowing headcount and venue first.” That’s there because Sofia got burned once, quoting a rough price before she had the details, then having to walk it back with an annoyed client. The rule exists because of a specific mistake, not a general worry.

“The honest answer before the deposit clears is ‘pending deposit,’ not ‘yes.’” This is the line doing the most work in the whole file. It doesn’t just say what not to say, it gives the actual replacement words. A rule that only says what to avoid leaves Claude guessing what to say instead. Give it the real phrase.

Check

Sofia’s business partner is drafting a second rule for a different situation: a client asking for a rush job, a wedding four weeks out instead of the usual six-month lead time. He’s written this so far:

## Rush requests
Never accept a booking under four weeks out without flagging it first.

That’s the “don’t” half, missing the same thing the deposit rule got right: the actual words to say instead.

Fill in the blank

Where it actually lives

One file, named CLAUDE.md, saved at the top level of whatever you’re working in. That’s the whole setup.

Build your own, right here

Five steps, nothing sent anywhere, and a real file at the end.

Sofia sits down on a Monday and works through six client files in one long session. A new venue quote for the Meyer wedding, an updated guest count for the Alvarez event, a vendor contract to review for a third couple. By the fourth client, something is off. Claude mentions a detail from the Meyer file while drafting the Alvarez proposal. Wrong couple, wrong numbers.

That’s not carelessness. That’s the context window filling up.

Everything in a session, every message, every file read, every command run, sits in one place while you work. It has a limit. As it fills, Claude doesn’t slow down, it gets less reliable, and it doesn’t announce when that’s happening. Anthropic’s own current guidance says this plainly: performance degrades as the context window fills, and Claude can start losing track of earlier instructions or making more mistakes. Confirmed by fazore-ai-expert, 2026-08-03, source: Anthropic, “Effective context engineering for AI agents.”

It’s a workspace, not a filing cabinet. A filing cabinet holds more the more you put in it. A workspace has a size limit, and once it’s full, something has to give.

Three real moments from Sofia’s Monday. For each, what should she do?

Sofia has three things to get done before lunch. A warm reply to a couple asking about availability. A dense vendor contract to check for anything unusual before she signs it. A quick check on whether her deposit math for a package adds up.

Same person, same afternoon, three different jobs. They don’t need the same tool.

Picking a model isn’t picking a favorite and sticking with it. It’s picking who’s suited to this specific task, the way Sofia wouldn’t ask her calligrapher to negotiate a vendor contract.

For each of Sofia’s three jobs, what matters most?

Model names change every few months. The tiers underneath them don’t move nearly as fast: something fast and cheap for simple, well-defined jobs, something balanced for most everyday work, and something built for genuinely hard, ambiguous problems. Learn the tiers, and the current names will make sense whenever you check them.

Checked 4 August 2026: the fast, cheap tier is Haiku 4.5. The balanced, everyday one is Sonnet 5. The top tier, for deep reasoning and genuinely ambiguous, long-running problems, is Opus 5 or Fable 5. Haiku is the exception worth knowing: it holds less at once and its knowledge stops earlier than the others, so it suits a quick well-defined job rather than a current-facts lookup. Check the lineup before relying on this list, it will be out of date eventually, that’s the whole point of this screen.

Three quick checks, tied to Sofia’s afternoon:

Check

Recap

One thing to do this week: write a real system instructions file for something you’re actually working on, using the five-step builder from screen 4. Keep it, and the model-choice reasoning from this lesson, as something to reuse, not something you did once and forgot.