Verification Before Completion

Wrong skill? Commit/push checks -> unified-commit-gate. Whole-repository health -> holistic-repo-verification. Branch integration -> finishing-a-development-branch.

Strategy before execution

Before every automated review or test/check pass, resolve a snapshot-bound REUSE, WAIT, RUN_MINIMAL, REVIEW_REQUIRED or STOP decision at its supported execution/dispatch boundary. Reuse valid coverage or join its active producer. Missing/stale decisions refuse; unknown coverage stays conservative. No model calls or recursive checks inside strategy. Status/HEAD changes, clean reviews and score targets alone never justify another expensive pass.

Evidence contract

Every completion claim needs evidence. Evidence remains valid while its tested content, coverage, runtime, dependencies, and relevant environment are unchanged. A new message, commit SHA, branch, PR, or merge commit alone does not invalidate it. Do not confuse checking evidence with executing the same validation again.

Procedure

1. Name the claim and its actual target: file, tested tree, deployment, PR, or runtime.
2. Find the existing result and its tested inputs, suite, context, verdict, and log.
3. Reuse a valid result. If the equivalent run is active, wait on that run; do not launch a second one. In superpowers-plus, tools/test-all.sh and its CI own test receipts; elsewhere use the active repository's equivalent runner and policy.
4. If relevant inputs changed or proof is missing, run only the required missing validation through the authoritative runner. Explain the invalidation reason.
5. Read the result. A failure, cancellation, timeout, skipped check, missing receipt, or unverifiable producer never becomes PASS. Do not write receipts or sentinels.
6. Check loose ends within the assigned task. Resolve must-address items; disclose deliberately deferred issues and version/platform limitations.
7. Report the observed result and stop when the user's acceptance criteria pass.

Reviews and sentinels

Use the repository's read-only readiness/parser tools, not an invented SHA grep. In superpowers-plus run tools/push-readiness.sh --json against the actual target range; do not assume another repository provides that helper. Its native consumers recognize content-scoped review clearance across unchanged merges and amends. A different HEAD SHA is not by itself a reason for another review.

• Missing or invalidated clearance: use the active repository's review routing (tools/review.sh in superpowers-plus).
• Valid clearance and unchanged reviewed scope: reuse it; do not dispatch again.
• Uncommitted relevant changes: review the actual changed snapshot before claiming it is covered. Ignore unrelated work only with an explicit scope boundary.
• A material finding or new relevant change requires delta review; a clean review does not require an arbitrary second round.

Progress and completion are different

A progress update may report an existing command's observed status. It does not invoke tests, review, repository-health audits, or TODO maintenance again. During an external wait, keep one watcher and its saved log; do not reload skills or reopen settled design decisions. A brief status update is not a new work unit.

Before waiting, distinguish required acceptance/release checks from advisory or unrelated post-merge health checks. Never bypass a required check. Do not expand completion into an unrequested audit, a new promotion, or a wait for unrelated workflows. Use holistic-repo-verification for an explicit health audit.

Claims and evidence

Do not repeat work to manufacture freshness

• Do not rerun the full suite because another skill also asks for verification.
• Do not rerun a review because a merge changed only history or metadata.
• Do not replace a reusable receipt with a hand-written success assertion.
• Do not treat a cache hit as wider coverage than the producer actually ran.
• Do not run global task maintenance when this task has no owned task-list changes.
• Do not call a partial result complete; name the missing acceptance criterion.

Failure cases