Verification

/review reads the diff and asks "is the code right?". /verification runs the work and asks "does it do what was asked?". It selects tests and real-path checks by verification scope. A passing suite alone does not prove a changed user flow works.

Proof standards and the recipe shape are adapted from pstack's create-verification-skill, maintain-verification-skill, and prove-it-works (MIT). The no-fallback rule and the saved recipe follow Claude Code's /verify.

Read when

• Every run: doctrine.md.
• Picking checks: the ways to verify. Finding and running suites: repository test suites. Writing or updating the app recipe: the recipe template.
• UI checks: user-experience.md and docs/design.md (ux:source-of-truth, ux:quality-floor).
• Reading terminals and logs: Verify terminals first.
• Before asking the user anything: Asking the user. Write reports in plain language.

Pick the target

• Started by an execution skill: use the parent's pinned revision/diff, Done when, rules that must stay true, slices, and test decisions. Follow that skill's review/verification ordering and return the handoff to that parent.
• Started by the user: verify the current work, a branch, or a PR checkout. Take Done when from the user, then the ticket or PR, then the diff. If none exists, ask once.