Verification

Four ways to make “did it work” structural instead of something you type every session.

Claude stops when the work looks done. Without a check it can run, “looks done” is the only signal, and you are the verification loop. You already know this, which is why “tell me how to verify it in the browser” is a sentence you have typed. Each option below trades setup for attention, in order.

In the prompt

The cheapest form. Give the check in the same message as the task, and ask for the evidence rather than a description of it.

Fix the double-booking bug in the group scheduler. Write a failing test that reproduces it first, then fix it, then run the test file. Paste the test output.

As a goal

/goal sets a completion condition that a separate evaluator re-checks after every turn. Claude keeps working until it holds or the evaluator judges it impossible. Useful for anything with a pass/fail you can state in a sentence.

/goal all tests in src/scheduling pass and the build exits 0

As a hook

A Stop hook runs your script when Claude tries to end the turn and blocks it until the script passes. This is the version that lets an unattended run finish correctly. Claude writes the hook if you ask.

Write a Stop hook in .claude/settings.json that runs `npm test -- --silent` and blocks the turn from ending while it fails. Show me the file.

Claude Code overrides the hook after 8 consecutive blocks so a broken test cannot trap a session forever.

In the browser

The Chrome integration lets Claude drive your real browser, take a screenshot, and compare it against a design. For UI work this is the check that matters, and it is the one you were doing by hand.

Open localhost:4200/schedule in Chrome, create a linked appointment with two pieces, take a screenshot, and compare it to the mock in docs/mocks/linked.png. List the differences and fix them.

/verify does a version of this against the running app after Claude’s own check passes.

The rule underneath