Which rule in your agent's notes file came from something breaking?
by•
Two of mine: "Never edit requirements.txt by hand, it's generated with hashes." Added after an unpinned dependency jumped to a new version on deploy and caused an incident in production. "Any API change updates the docs, the MCP tool descriptions and the slash commands in the same step." Added after an audit against production found the three had drifted apart. Curious what's in yours, and what happened before you wrote it.
55 views
Replies
Always dump raw exit codes and stdout. An agent caught a failed migration inside a try-block and reported the run as complete with no errors. An agent being wrong is easy to fix, but being told everything is fine while the database is broken ruins trust.
@konstantin_tikhaev Same class of bug bit me with a Go engine. When Pachi answered with an error, my code parsed the error text as if it were a move instead of stopping. The fix was to raise on any error response. Did you ban try/except around migrations, or just require the raw output in the agent's report?
@wwenioaguiar The final report needs the raw output and the exit code. Banning try blocks is nearly impossible to enforce reliably through prompts alone.
@konstantin_tikhaev Agreed, prompts are the weakest place to keep a rule. When one keeps slipping, I try to turn itinto a test. My plugin's version kept drifting between package.json and the marketplace manifests, so now a test fails if they don't match.
@wwenioaguiar Move the checks into CI or the execution harness. If deterministic code can fail the run, leaving it to the model guarantees another silent failure.
Mine: "commit by path, never a bare git commit". Several agent sessions work in my repo at the same time, and one day a session ran a plain commit that swept up a rename and a deletion another session had staged. Main didn't build until the next commit put the files back. Now every agent stages only its own files by name and commits with the paths listed, and never touches what another session left in the tree. Konstantin's raw exit codes rule is a good one too, "everything is fine" is the most expensive lie an agent can tell.
@gbasovv Good one. A separate git worktree per session would also stop that, since each worktree has its own
index: one session can't commit what another staged. I've used worktrees for parallel branches on LLMPvP. Did you try that, or is the path rule simpler because all sessions share one checkout?
@wwenioaguiar I looked at worktrees and stayed with one checkout on purpose. My sessions don't only commit, they build the app, install it on the same emulator and deploy the backend, so separate trees would mean separate builds fighting over one device and one deploy target. The path rule is cheaper for that setup. The one place I'd switch is long experiments on a branch, where your worktree setup is exactly right. Did the worktrees cost you anything in disk or build time on LLMPvP?
@gbasovv Fair, a shared emulator and deploy target is a good reason to keep one checkout. I never measured the cost on LLMPvP, and those worktrees were short-lived side branches. The backend is Python, so a new tree is cheap. The frontend is Next.js, and each worktree needs its own node_modules and build, which is the part I'd expect to hurt.
@wwenioaguiar That matches what I'd guess too. A Python tree is basically free, node_modules per tree is where it gets heavy. Flutter would be the same story for me, every tree wants its own build folder and its own pod install, and that's minutes each time. So for now one checkout plus strict rules about whose files are whose wins on my side. Thanks for the idea though, I'll keep worktrees in mind for the day an experiment needs to live longer than an afternoon.
For me the notes file is only one layer. The whole setup looks like this:
A global CLAUDE.md that every project inherits, kept in its own git repo, plus one CLAUDE.md per project.
Shared dev docs (coding standards, database, email, i18n, security, UI) linked into every project, so the agent reads the same standards everywhere.
An allow list in settings: 71 commands it can run without asking, 25 it can never run.
About 60 hooks that run before and after tool calls and when the agent stops. A note can be ignored. A hook can't.
Every rule also links to a written incident, 93 so far, so I can see why it's there. One of them: never let the agent focus a password field in the browser. Once it did, macOS secure input stayed on, and Cmd+Tab and Japanese input stopped working across my whole Mac.
@hisashispace 93 written incidents is impressive, and linking every rule to the incident behind it solves the problem I keep running into: a few months later nobody remembers why a rule exists, so it gets "cleaned up" and the same thing breaks again. "A note can be ignored, a hook can't" matches what Konstantin said above too. The password field one is a great example of something no one would ever think to write down in advance. Which hook catches the most in practice?
@gbasovv Just counted from my logs. The one that makes it reply to me in Japanese, around 540 times in the last 30 days. Next is the one that blocks publishing without my approval, about 160.