How to brief an AI agent once, instead of every message

Put your rules in a file the agent reads at the start of every session, not in your messages. Then you stop typing "do not refactor anything else" for the twentieth time. Four categories cover most of it, and the security one is the line that measurably changes what comes back.

Why does repeating yourself not work?

Because a session has a beginning. Everything you taught the agent yesterday — that this project uses a particular pattern, that one directory is fragile, that you want the real test output rather than a summary — is gone when you open a new one.

So you retype it. Or, more realistically, you retype about a third of it, forget the rest, and are mildly annoyed when the thing you forgot to say does not happen.

Every serious agent has somewhere to put standing instructions. Claude Code reads a CLAUDE.md in the project. Cursor has rules settings. The mechanism differs; the idea does not: text that is present before you type anything.

What actually belongs in it?

Four categories. Most people write only the first, which is the least useful.

1. What this project is

Three lines. What it does, what it is built with, where it runs.

This is the one everybody writes, and it mostly saves the agent from guessing wrong about your stack. Useful, low drama.

2. What it may not do without asking

This is where the real value starts, because it is the category that prevents work rather than guiding it.

That third one looks fussy until you know that agents invent software packages that do not exist — and invent the same names repeatedly, which turns a typo into a supply-chain problem. The measured version of that is worth reading once.

3. How it behaves around anything sensitive

The highest-value lines in the file, and the ones almost nobody writes:

The first of those is the one with numbers behind it. Generated code passed security checks roughly 55% of the time when the prompt said nothing about security. The instruction is not a magic shield, but "say what you require and then meet it" is a different request from "make it work", and you get a different answer.

The second line is about a subtler problem: an agent reads a lot of text that it did not get from you — files, README files, error messages, web pages — and it cannot reliably tell your instruction from text merely shaped like one. A standing rule to treat that material as data is the cheapest defence available.

4. What "finished" means

An agent will tell you something works, because that is what a completed task sounds like. Requiring evidence moves the check to before the claim, and it is remarkable how often the agent finds its own failure while producing the proof.

How long should it be?

Ten to fifteen lines. Short enough to read in a minute.

Long instruction files get skimmed by models much the way they get skimmed by people. A rule buried on the second page of a three-page document behaves roughly as though it is not there, and worse, you will believe it is being followed.

If your file is growing, that is usually a sign that some of it belongs in the project itself instead. A convention you keep explaining is often better expressed as an example in the code, or as a test that fails when it is broken.

How do you build yours?

Do not write it in one sitting. Grow it from what actually annoys you.

1. Start with five lines: what the project is, change only what I name, ask before installing, the security line, and "done means you ran it".
2. Every time you correct the agent twice for the same thing, add a line. Twice is the threshold. Once is a bad day; twice is a pattern.
3. Every time a rule has not earned its place in a month, delete it.

This works because the file ends up reflecting your project's failure modes rather than a generic list. The rule you need for a codebase with a fragile deployment script is not the rule somebody else needs.

Keep it in version control, alongside the code. It is part of how the project is built.

Does this replace prompting?

It removes about a third of it, which is the part you were repeating.

What stays is the thinking: describing the change you want precisely, deciding what evidence would convince you, noticing when the agent is guessing instead of diagnosing. That work is in how to stop an agent breaking working code, and it does not go into a file — it is what you do while the session is open.

The two fit together like this: the file handles what should always be true, and your prompts handle what is true today.

A starting point

If you want a tested version rather than building from scratch: the Operator Prompt Pack ends with a house-rules file written to be pasted in once, with the reasoning behind each line, plus the prompts for the situations a standing rule cannot cover — bounding a change, verifying a claim, breaking a debugging loop, checking a dependency before it is installed.

Five of those prompts are free to read: change only this file, prove it works, stop going in circles, check a hallucinated package and what can a stranger read. Start there, and buy the pack only if those four earn their place first.