Rules in One Place — How to Write an AI Rules File (2)

If you're repeating the same instruction to AI for the third time, that's not a conversation — it's a signal to write it down as a rule.

Rules spoken aloud leak away

"Don't touch the raw data." "Always cite a source for numbers." "Put results in this folder by date." Work with AI for a while and you find yourself repeating the same instructions every session. A spoken rule vanishes when the session ends, and in the next session an AI that has forgotten it overwrites the original or hands you numbers with no basis.

As we saw in the previous article, AI can't remember across sessions. So rules belong not in conversation but in a file the AI reads on its own at the start.

Rules files that are already a standard

This isn't a story about one tool — it's a practice that has taken hold across AI coding tools broadly.

• CLAUDE.md — Anthropic's Claude Code automatically loads this file into context when it starts a session. You can split global rules from project-specific ones (official docs, best practices).
• AGENTS.md — An open standard tied to no single company, billing itself as "a README for agents." By the site's own count, more than 60,000 open-source projects use it, and some 20 tools support it, including OpenAI Codex, Google Jules, Cursor, and Copilot (agents.md).
• Cursor rules — Put project rules as files under .cursor/rules/ and they're injected into the agent's context (the single .cursorrules file is being retired as legacy, official docs).
• GitHub Copilot repository instructions — Write them in .github/copilot-instructions.md and they apply automatically to every conversation about that repository. Introduced as a public preview on January 21, 2025 (GitHub changelog).

The names and locations differ, but the principle is one and the same. Gather the always-follow items in one place, and have them read automatically at the start.

Rules that get followed vs. rules that get ignored

Creating a rules file and getting those rules actually followed are two different things. The difference is in the sentence.

Rules that get followed	Rules that get ignored
"The raw data/ is read-only; processed output goes in outputs/"	"Be careful with the data"
"Attach the eval-set version and sample size (n) to reported numbers"	"Be thorough"
"External posting (tracker, wiki, messenger) only after a draft check"	"Last week's experiment came out roughly like this"

There are three principles.

• In verifiable sentences — For something to be a rule, you have to be able to judge whether it was followed. "Be careful" can't be judged.
• Short — A rules file is read in full every session. The longer it is, the more it costs each time. Anthropic's docs also recommend keeping it concise.
• Leave out one-off facts — Status like "last week's experiment result" belongs in a note, not a rule. Keep only always-follow items in the rules.

Put rules common to all your work in the global file, and rules that hold only within a given project in that project folder's file.

What rules can't hold — habits and facts

There's one boundary. Automation that must fire without exception — "from now on, always do that whenever this happens" — is safer handled by a mechanism that a program enforces at a fixed point (a hook) than by a rules file. A rule can be skipped if it isn't read, but a hook always runs. We'll return to this in a later article.

And one-off facts and lessons like "the trap that took half a day to find last time" belong to memory, not to rules. We pick that up next — One Fact Per File.

If you'd like to make a rules file your team standard, we can share the rules framework we use to run several services under one system, via Contact.

---

The "Using AI as a Colleague That Remembers" series

1. Why AI Forgets Yesterday — Session Amnesia and the Cost of Context
2. Rules in One Place — How to Write an AI Rules File (current article)
3. One Fact Per File — Automatic Memory
4. To the Me of the Next Session — Daily Notes and Handoff
5. Promoted to the Team's Language — Trackers, Wikis, and Git
6. Pitfalls and a 4-Week Adoption Roadmap