Guide
6 rules that make your coding agent prove it works before it says done
Coding agents have a habit of saying a feature is “complete and working” without ever opening it. We hit this in Otto too: one model never ran its own check and reported success anyway.
The fix is one idea. Nothing is done until something other than the builder has seen it work. These six rules turn that idea into instructions, close to word for word what Otto runs.
The six rules
Rule 1: Plan in things the user will see, before the first edit.
Before your first edit, write your task list: one item per visible change you are about to make.
It keeps the agent from wandering into refactors nobody asked for, and gives you a list to check against.
Rule 2: Never leave it unable to build.
Never leave the app unable to build. If a screen imports a file, that file must already exist.
Agents like to import a file they plan to write later, then forget it. This one rule is what keeps the preview from turning into a blank error screen.
Rule 3: Fix problems the moment they appear.
After every edit, check for errors. Fix them before moving on; never leave a problem for later.
Errors pile up fast. Ten small ones are much harder to untangle than one.
Rule 4: Use it like the person who asked for it.
Try your change the way the user will: open it, go through the whole flow. Do not report work you have not seen working.
Submit the form, then find the item in the list. Loading the page proves nothing.
Rule 5: A separate checker judges it against the original request.
Give a second agent, one that can’t edit files, this brief:
Judge the user’s exact words, not the builder’s summary. Go through the whole flow and confirm the result is really there. Text cut off, a step that changed nothing, or a “coming soon” placeholder is BROKEN. Reply VERDICT: WORKS or VERDICT: BROKEN, with the problems and where they are. No praise.
The “user’s exact words” part matters most. It catches the agent quietly building something easier than what you asked for, like a fixed dropdown when you asked to type your own value.
Rule 6: “Done” needs a WORKS verdict that came after the last edit.
If you changed anything since the last WORKS verdict, run the checker again. Do not finish until it reports WORKS.
Without it, the agent checks once, makes “one small fix”, and ships that fix unchecked.
The trade-off
Every change takes longer and costs more, because it gets built and then checked. So cap the loop: stop after 3 rounds of BROKEN and treat that as a failed change, instead of letting it spin.
All six as one block
Paste it into CLAUDE.md, .cursorrules or any agent’s system prompt.
Before your first edit, write a task list: one item per visible change.
Never leave the app unable to build; never import a file that doesn't exist yet.
After every edit, check for errors and fix them before moving on.
Try every change the way the user will, end to end. Never report work you haven't seen working.
When you think you're done, ask the checker (a separate agent that cannot edit) for a verdict.
The checker judges the user's exact request, completes the whole flow, and replies
"VERDICT: WORKS" or "VERDICT: BROKEN" with concrete problems and where they are. No praise.
You are done only when a WORKS verdict came after your last edit. Stop after 3 BROKEN rounds and report what is still broken.