Here's a quirk that surprises everyone at first: the agent has no long-term memory. Close the window, come back tomorrow, and it remembers nothing about how you like things done — your conventions, the things it should never touch, the way your week runs. It's brilliant and it has amnesia. So left to itself, it guesses, and you end up re-explaining the same things over and over.
The answer is a plain text file that lives with your project. Before the agent lifts a finger, it reads that file — so whatever you wrote there becomes its standing orders for the session. No code. Just rules, in the same words you'd use to brief a new hire on their first morning:
- Always show me the result before you send anything to a customer.
- Never touch the billing spreadsheet — read it, don't change it.
- Reports go out Monday mornings, never any other day.
- When you're not sure, stop and ask me — don't guess.
That's the whole idea. You write the rules in plain English; the machine reads them first and works inside them.
Same idea, different name on the door
Every tool has its own name for this file. With Claude Code it's CLAUDE.md. With Codex it's AGENTS.md — a shared standard a growing number of tools now read. Others use their own names again. Don't get hung up on which: they all do the same job — a file the agent loads automatically so it begins already knowing your rules. (If you run both, they can even point at each other, so you write the rules once.) The .md just means Markdown, a fancy word for plain text with the occasional heading. You write it like a notepad.
What's worth writing down
The useful stuff is whatever the machine can't figure out on its own — the things that live in your head, not in the work itself. A few kinds earn their place:
- How you do things here. "Reports go out Monday." "We call them members, not customers." The conventions a newcomer would have to be told.
- The lines it must not cross. The single most valuable kind of rule is the never: never delete anything without asking, never email a customer directly, never change the billing data. Saying what's off-limits prevents the mistakes that actually scare you.
- What looks wrong but is right. If there's a thing the machine will be tempted to "fix" that's actually correct on purpose, write it down once so it stops second-guessing it.
Notice what these have in common: none of it is technical. It's judgment — yours — written down so the machine repeats it instead of inventing its own.
The one rule everyone learns the hard way
This is the part people get wrong, so take it as the headline: keep it short. It's tempting to write down every preference you've ever had until the file becomes a manual. But a long file backfires in the worst way — past a certain point the machine stops following it at all, the way your eyes glaze over a ten-page terms-of-service. It doesn't carefully skip the boring parts; it tunes out the whole thing. A few sharp rules beat a hundred fuzzy ones.
A page it actually follows
- A handful of rules that genuinely matter
- Every line you'd defend if asked
- Short enough to skim in a minute
- So it gets read — and followed
A wall it tunes out
- Every preference and edge case piled in
- The rules that matter buried in the noise
- Too long to ever re-read
- So it gets skimmed past — and ignored
The test that works: if you couldn't skim it between two meetings, it's too long.
Two more traps worth dodging, both versions of the same thing — a rule that isn't really true. Don't contradict yourself (two rules that fight leave the machine guessing which wins), and don't let it go stale. A rule that used to be right but isn't anymore is worse than no rule at all — it's confidently steering the machine wrong. When the way you work changes, change the file. It's a living note, not a monument.
Why this is the whole skill, really
It's easy to assume directing an AI must involve something technical. It doesn't. It's this: knowing your own rules clearly enough to write them down, then keeping the list short and honest. That's not a programming skill — it's a thinking-clearly skill, the same one a good manager uses to brief a team. The machine does the building. You decide the rules it builds inside — and a plain text file is where you say so.