The first rule in the file every one of my Claude sessions reads is written in capitals, and it says never lie to the user, by accident or on purpose. The accidental kind looks like a confident “it should work” from an agent that never ran anything, or a figure that sounds right because it came from somewhere plausible.
That file is my global CLAUDE.md, my operating model for working with agents. It casts the main session as the leader of agents, tells it to prepare them well and hold them accountable, and expects the leader and the agents to be skeptical of each other’s conclusions. Before any strategic decision or any move off the plan, the session has to seek consensus with the agents, and when they disagree the conflict comes to me.
The rules that carry the most weight
Before starting a task and after finishing each piece of it, the session asks the ONE Thing question: what’s the one thing I can do such that by doing it everything else will be easier or unnecessary? Each answer is meant to narrow things, from the whole project down to the next concrete step.
Mock data is banned everywhere, and so are scripts that validate themselves against numbers someone typed into them.
Nothing comes to me for approval until I’ve been shown it in full. A plan, a script or a preview goes on a designed page that reads well on a phone, a table in the chat doesn’t count, and every revision updates that same page with the version number and what changed.
Planning and doing are separate commands
/plan has agents scrutinize the investigation and draft a plan, forbids them from editing any source code, tells them to keep asking clarifying questions until they’re at least 95% clear, and ends with a line in capitals saying the plan doesn’t run until I approve it. /execute carries out the approved plan with other agents checking the executing agents’ work, and it bans claiming anything is fixed until real tests have passed, along with phrases like “ready for production”. /scrutinize is one paragraph I can run on anything, and it asks what’s wrong with the work, whether it’s fragile, whether it serves the purpose and whether the agent knows the user and what they’re doing with it.
Three reviewers
Any plan that touches architecture, infrastructure, security or more than one file goes to three reviewer agents in parallel before it runs. The quality guardian wants file and line evidence for every claim and treats “it should work” as a cue to demand test output, and it gets no edit tool. The infrastructure guardian checks authentication and performance, keeps each user’s data walled off and never lets a user ID come from the client. The risk guardian is written as the antagonist, with a brief to say “yes, BUT here’s what could go wrong” and to look hard at second-order effects and whether a decision can be reversed.
Must-fix findings go into the plan before anything runs, and anything deferred gets written down with a reason.
What that looked like this week
On October 29 I put the main ideas for my website through the same treatment. The idea my lead agent recommended putting on top was teams of people and agents. The risk guardian searched what had been published lately and failed it on freshness, because Anthropic and Microsoft had both published on human-agent teams since early September. It failed it on proof as well, since my own work was thin support for a claim about teams. It recommended dropping the idea and pointed to the gap between a CEO and the builders as the stronger one, and that’s the main idea I picked.
A separate risk review checked the statistics in the research behind the site. It found one, credited to a large consulting survey, where half the figure appeared only in secondary coverage and the other half couldn’t be found anywhere, and marked it must-fix. The copy brief for the site now allows no statistics at all.
How much of this is enforced
Many of my agent and command files point back to the rules or carry the same five-question first check, and apart from a deny list that blocks the Gmail send tools, nothing in my settings stops a violation mechanically, so the rules hold at the level of instructions, because every session reads them. The quality and infrastructure guardians were written for one of my own products and the risk guardian for my personal finance agents, and still carry those specifics, so they need a rewrite before they review anyone else’s code.