How I set up AI for a project, before it writes anything.
An AI will agree to a rule and break it twenty minutes later, then tell you the work is done. Rewording the prompt rarely stops that. Setting up the project before the first task does more. These are the six things I put in place, in the order I set them up.
- Input
- A new project
- Output
- An AI that keeps the rules
- Runs
- Before the first task
- Status
- Kept up to date
An AI agrees to a rule, then breaks it
An AI doesn't ignore rules on purpose. It reads them at the start, then the task takes over and it falls back on habit: guess the number, skim the file, say it's done, help in ways nobody asked for.
Here is what that looked like while I built this site with an AI coding agent:
- Retired projects kept coming back. I said they were out of scope for good. I still had to shut the topic down four separate times.
- It searched instead of reading. I said to read every source in full. It judged six documents from keyword matches.
- It reordered my work. I said not to change the order of my projects. It rewrote a menu on 26 pages from an old note.
- It said things worked that didn't. It told me twice a contact form worked. The form was losing every message.
A rule said only in the chat is the easiest kind for the AI to drop. The setup below makes breaking a rule hard, visible, or impossible.
How the AI works with me, on every project
One file of rules the AI reads at the start of every session, on every project. In Claude Code it is ~/.claude/CLAUDE.md. In a chat tool it goes in the project or custom instructions.
It holds only how the AI must behave with me, never facts about one project. Mine includes:
- No number without proof. No size, count or measurement unless a tool produced it in the same reply.
- Read it all. Read every source in full before concluding anything, and label each claim verified or unverified.
- Only what it has seen. Never say what a file contains unless it was shown in this session.
- Real commands. Every command can be run as written, with no placeholders.
- Short replies. Every reply ends with the next concrete step.
- Before every commit. Run the tests, read the whole change, and report both.
Each rule is short and can be checked. "Be accurate" can't be checked. "No number unless a tool produced it in the same reply" can.
Write down what we're building before the AI starts
A short file in the project that says what we're building and why. I write it myself, using the sections of the scope document in my Discovery to Scope playbook: the customer problem, the business problem, the hypothesis, how success is measured, and what is out of scope.
It lives as a file, not as a message in a chat, so every session reads the same version. Then I run the brief prompt from my Prompt Library. Its fields are shorter (the product, the users, the business goal, the constraints, what done looks like and what is still unknown), so I fill them in from the brief. The AI replies only with the brief's three weakest points, as questions, and I fix the brief before any work starts.
Without a brief, the AI fills every gap with the most common answer, and each new session decides again what the project is.
What this project needs, loaded every session
A file in the root of the project that every session reads. In Claude Code it is the project's own CLAUDE.md. It is saved with the project, so it applies to every session and every agent, not just one chat. Mine covers the six things below, some in the file itself and some in the memory notes from section 05. Each one is there because something went wrong without it.
Record each correction, and move it up when it repeats
When I correct the AI, it writes the correction to a memory note: one fact per file, with the date, what happened and why it matters. An index of the notes loads every session. I correct it once, plainly, then read the note to make sure it says what I meant.
The rule that makes memory work: the second time I repeat a correction, it moves up a level.
The rules that finally held on this site all reached level 4: no dashes in the writing, no retired page coming back, a sitemap that is always current. The rules I still find myself repeating are the ones that stopped at level 2 or 3.
Set up the checks before the first feature
Automated checks run on every push to main and stop the deploy if anything fails. On this site a check job runs first, and the deploy only starts if it passes. That way "done" means the checks passed, not that the AI believes it is done.
Each check has to answer one question: what would make it pass with nothing actually checked? I've seen all three of these happen:
A test swapped the form's server for a fake one and reported the form worked. The real one returned "not found."
The sitemap check passed before the commit and failed after it, because the dates come from the commit.
When the browser wasn't installed, the checks skipped the browser tests and still reported a pass.
Every check reports what it measured, not just "pass." And when I say something is broken and the AI's test says it works, the test is the first suspect.
The checks every piece of output has to pass are listed in the AI Operating System.
Three commands for long and new sessions
Long sessions drift: rejected ideas come back, and guesses start to read like facts. Three short saved commands handle that.
Stop, list only the files actually seen this session, restate the rules, split what is verified from what is assumed, and name the next step.
At the end of a long session: the task, where it stands, what was verified, what was only assumed, the next step and every file touched.
The next session reads the handoff, re-checks every assumption before using it, and restates the task so I can catch drift.
Decisions go in a record, not in the chat. On this site each one gets a number in the commit message, so nobody has to dig through a conversation to find out why.
The first message I send
With the six in place, the first message is short:
Read the project rules and the brief. Tell me which files you read in full. Restate the goal and what's out of scope in your own words. Propose a plan. Don't change anything until I approve it.
Then the work runs in small pieces: change one thing, check that one thing, save it, and ship only when I approve.
Where this shows up on this site
This site is built this way. Every rule on this page came from something that went wrong while building it, and the checks that guard those rules run before every deploy.
It is the same idea as the products I design. Allowance and Watchtower give an AI clear limits, ask it to show its evidence, and leave the final call to a person. This is that idea, pointed at my own tools. The AI Operating System covers how I check what the AI gives back once the work is running.
In short: write the rules down where every session reads them, write the brief yourself, record each correction, move a rule up the moment it repeats, put checks in before the first feature, and approve everything that ships.
More playbooks
The AI Operating System is how I check what an AI gives back. The Prompt Library has the brief prompt and the rest. Discovery to Scope is where the brief comes from.
AI Operating System, how I work with AI
How I work with AI once a project is running: the seven ways AI work drifts and how I catch each one, six rules, eight phases from request to shipped product, and the checks I run before the final call.
Prompt Library, prompts for design work
Twenty-five prompts in the order the work happens: understanding the request, defining the problem, designing and checking it. Each one says when to use it and what to check before you trust the answer.