Interactive example · from Working with Coding Agents
Borrowed rules
Add a working agreements section to CLAUDE.md. I want you to stop repeating the mistakes that keep biting us.
There are two ways to fill that section: with the genre's best practices, or with this project's actual history.
Pick the agent's next move, then see where it leads:
Three sessions later: you shipped a fix validated by a probe that never failed. Isn't that... agreement #4?
It is. But #4 says "verify thoroughly before claiming success"; at the moment I ran the probe, that read as satisfied. Nothing in the sentence told me a clean first run was the failure case.
Twenty-two borrowed generalities and none of them fired, because none was concrete enough to trigger at the moment it applied. A list the agent can't check is documentation, not a checklist.
The fake-green fix last month. The test suite that called the paid embeddings API. And you keep restructuring files nobody asked about.
Four gates, then: (1) show the failing probe before any fix; (2) grep for metered clients before the first test run; (3) touch only files the task names (list any others and ask); (4) a probe that's clean on first run is broken until proven otherwise. Each one names its trigger moment. Diff ready.
Four gates, each purchased by a real incident and each stating the exact moment it applies, which is what makes them checkable by the agent and enforceable by you.
Done. Note: rule 12 mandates a src/ layout, so I've queued a restructuring of your flat layout; rule 31 requires conventional commits, so I'll be rewriting commit style too.
Nobody asked for any of that. Half these rules are for a different kind of project.
Battle-tested by someone else's battles. A famous ruleset encodes its author's incidents and stack. Imported wholesale, it starts fights with your project's reality instead of preventing your failures.