| name | verify-change |
| description | Verify a change actually works by exercising it end-to-end and observing real behavior — not just green tests. Use before declaring any nontrivial change done, before opening a PR, or when the user asks "does this actually work?". |
| source | AM pattern B2 ("give it a check it can run" — the single most important pattern); Anthropic verification guidance |
| am_pattern | B2 |
| triggers | ["verify the change","verify it works","prove it works","end-to-end check","did it actually work"] |
Green tests are necessary, not sufficient. You are verifying the change by driving the
affected flow the way a user or caller would and observing the outcome. This is the
check that separates a session someone must babysit from one they can walk away from.
Procedure
- Name the claim. One sentence: "this change makes X happen under Y." If you can't
state it, you can't verify it.
- Run the standing checks — the repo's full test suite, build, lint/typecheck (see
AGENTS.md Commands). Any failure stops verification; report it as-is, never as
"mostly passing".
- Drive the real flow. Pick the cheapest honest end-to-end exercise:
- API/service change → real request against a locally running instance; inspect the
response and the side effects (DB row, emitted event, log line).
- CLI change → run the actual command on a realistic input.
- UI change → open it in a real browser; click the path; screenshot the result.
- Bug fix → replay the original reproduction and watch it not happen.
- Probe one boundary. The empty input, the unauthorized caller, the double-submit —
whichever edge the change plausibly moved.
- Report with evidence. State what you ran and what you observed (command + output,
screenshot, response body). "Verified: ran X, observed Y" — never "should work now."
Rules
- If you cannot run the flow (missing credentials, no local env), say exactly that
and list what a human must do to verify — do not substitute confidence for evidence.
- A verification that would pass even if the change were reverted is not a verification.
When in doubt, revert mentally: what observable difference does this change make?
- New behavior worth verifying is usually worth a permanent test — if step 3 caught
something the suite didn't, that's a
compound-learnings entry.
