Verification Before Completion
No claim of "done" or "tests pass" without fresh evidence from actually running the check — including hedges like "should" or "looks like"
The skill addresses a concrete task: verification before claiming completion, committing, or creating a PR. Its evidence-before-assertions principle, gate sequence, and examples for tests, builds, requirements, regression tests, and agent delegation provide strong practical value. Evidence gaps include no explicit boundaries for choosing applicable projects or commands and no complete alternative process when verification cannot run.
The sequence of identifying a proving command, running the full command, reading output and exit status, and reconciling the result is consistent and oriented toward reproducibility. It also covers regression-test red-green verification and independent checking of agent reports. Evidence gaps include no method for discovering commands and no detailed handling for missing tools, incomplete environments, timeouts, nonzero exits, or ambiguous output; there is also no skill-specific behavioral test evidence.
The skill reduces the risk of false completion claims and unverified commits or PRs, and requires checking the VCS diff after an agent reports success. It requests no credentials, network access, or specific file changes, and shows no malicious or destructive default. Safety remains limited because running a “full command” can cause build, test, commit, or other external side effects; the skill lacks least-privilege guidance, consent gates, sandboxing, sensitive-data handling, failure rollback, and command safety review.
The skill explicitly requires fresh verification evidence, full-output reading, exit-code checks, and failure counts, while distinguishing claims such as tests passing, builds succeeding, and requirements being met. Evidence gaps are material: the command results in the examples are illustrative text, not execution records available to this static review; the “24 failure memories” statement has no corroboration in the supplied skill; and there is no independent evaluation, test result, or explicit fact-versus-inference labeling for this SKILL.md.
Triggers are clear, and the iron law, gate function, failure list, and common patterns are easy for a coding agent to apply. Evidence gaps include no setup or harness requirements, input/output contract, cost or duration guidance, compatibility details across agent tools, troubleshooting examples, or safe exit/reporting behavior when verification is blocked.
The target file has name and description metadata; shared repository material provides limited maintenance context through the MIT license, version 6.1.1, contribution process, issue channel, and update note. The skill itself has no version, changelog, named maintainer, release responsibility, or dedicated update path. Publisher provenance is not verified by the FollowSkills enterprise registry and therefore cannot add governance credit.
- Do not interpret “run the full command” as unconditional permission to execute commands that may commit, delete, deploy, or access external systems; review side effects and obtain consent when needed.
- If a verification command fails, is unavailable, or produces ambiguous output, do not claim success; report the actual state, blocking reason, and unverified scope.
- This assessment is static only: the skill, commands, and tests were not executed, and repository test material is not a substitute for skill-specific behavioral evidence.
What it does & when to use it
The shortest but most uncompromising skill in the set: its core position is that claiming completion without verification is dishonesty, not efficiency. Before making any completion or passing claim, it requires identifying exactly what command would prove the claim, running it right then, reading the full output, and confirming the output actually supports the claim — only then is the conclusion allowed. Getting the order wrong or skipping any step counts as a violation.
Provides a claim → required evidence → insufficient evidence table (e.g. "tests pass" needs a fresh test-command output showing 0 failures — "ran earlier" or "should pass" don't count). Lists a red-flags checklist: hedging language ("should", "probably", "seems to"), expressing satisfaction before verification ("great!", "done!"), and trusting a subagent's own success report without independent verification — all of these mean stop immediately. Gives a concrete red-green verification procedure for regression tests (write the test → run it, passes → revert the fix → run it, must fail → restore the fix → run it, passes again) that proves the test actually detects the original bug, not just that it appears to. For subagent-reported completion specifically, requires checking the actual version-control diff instead of trusting the report text alone.
- Before any "tests pass," "bug is fixed," or "build succeeds" claim, run the corresponding command fresh for current-turn evidence rather than relying on memory of a previous run
- After a subagent reports "task complete," check its actual committed diff to verify the change instead of taking the report text at face value
- After writing a regression test, verify with the red-green cycle that it actually catches the original bug (reverting the fix must make the test fail) rather than assuming it's valid once written
Pros & cons
- The claim → evidence → insufficient-evidence table turns "what counts as verified" into a checkable, concrete standard instead of an unenforceable "be careful"
- Requiring extra verification specifically for subagent success reports targets a real, easily overlooked trust trap
- The regression-test red-green procedure (reverting the fix must reproduce the failure) is a genuinely useful concrete technique that proves a test is effective rather than just looking like it tests something
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- Requiring fresh run-evidence for every small conclusion can noticeably slow the feedback loop when verification itself is expensive (a run that takes tens of minutes), which is a real trade-off to weigh
- Like every other Superpowers skill, a self-imposed rule like this only works if the model actually follows it — there's no external enforcement mechanism
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Triggers automatically before any completion/passing/fixed conclusion, and before committing, pushing, or opening a PR. Also explicitly referenced downstream by subagent-driven-development and systematic-debugging to gate completion claims at each stage.
Compared to similar skills
Compared to no such rule — the model concluding from a previous run or its own judgment — this skill tightly binds "completion claim" to "fresh verification evidence," directly targeting the common agent failure mode of reporting success prematurely. It complements test-driven-development's "write the test first" — one governs how code gets written, the other governs how results get reported.