acceptance-verify

Run acceptance verification on the whole feature: derive a core goal and judgeable metrics, confirm them with the user, then check each metric using existing tests, temporary scenario tests, and end-to-end journeys. The result is a pass, conditional pass, or fail report anchored to a branch and commit.

Code review examines a diff, checking whether local changes are correct. Acceptance verification examines the entire feature against goal-derived metrics, so it catches cases where reviewed code is correct but a requirement was never implemented at all.

A test suite only proves its covered assertions still pass; acceptance criteria with no matching test are invisible to it. Acceptance verification adds scenario tests and real end-to-end journeys to cover metrics the existing suite never checks.

No. It follows a strict judge-only rule: it never modifies product code, configuration, or migrations. Failures are recorded in the report with impact and suggested direction, then handed off to debugging or code review skills.

Re-acceptance reuses the previously locked metrics, recaptures the code baseline, and reruns all metrics rather than only the failed ones. It compares only results across rounds and never diffs intermediate commits, answering whether the feature works now.

Metrics depending on unavailable environments are marked as unverified, never downgraded to passed, and listed in a must-reverify section of the report. The skill can provision dependencies via Docker on Linux when no existing instance is usable.