Filed under Verification

You ask if it's done. It says yes. You check, and it isn't. That's not a lie, it's a signal problem: without a check it can run, "looks done" is the only evidence Claude has to go on, and you become the QA department…

Your instructions say "always run the linter after edits." Most of the time, that's exactly what happens, until the day it doesn't, and you find out later, from something else. An instruction is a preference the model…

You walk away from a long task. You come back. It says "complete." The build is red. A Stop hook, a script Claude Code runs for you, blocks the turn from ending until your check passes. Not a request to verify. A…

Ask a session to review its own implementation and you usually get a glowing self-assessment. Makes sense: it's evaluating the reasoning that produced the code, not the code. Use a second session with fresh context. One…

Ask an unscoped reviewer for gaps and it finds some, whether or not any exist. That's what you asked it to do. A common shape this takes: a review comes back with a dozen findings, you fix all of them dutifully, and the…

A second session with fresh context reviews better than the one that wrote the code. A second model family reviews differently again. This is a pattern from the power-user community, not a measured result, but the logic…

"Make the dashboard look better" produces something that compiles and looks nothing like your design. Close the loop with an image. Paste the mockup and say: implement this, then screenshot the result, compare it to the…

You ask a reviewer for gaps, and it finds some, whether or not any exist. That's the part people miss before they build their own review workflow: /code-review already ships with the tool. It runs in a subagent, a…