Verification Before Completion

What it does

This workflow targets the gap between having changed code and having proved the requested outcome. It asks the agent to identify the command that supports a claim, run the complete check, read its output and exit status, then state only the result that evidence establishes. It distinguishes a clean linter from a successful build, a passing test from satisfied requirements, and another agent’s success message from an independently checked artifact. The technique applies to handoffs as well as implementation.

When to use it

• Confirm a reported bug is resolved through its original reproduction.
• Validate a generated artifact or deployment before telling a stakeholder it is ready.
• Audit a delegated task that claims success without supplying checks.

Step-by-step workflow

1. Name the precise claim and select a command or observation that could disprove it.
2. Run the full relevant verification on the actual final tree or artifact, using fresh evidence.
3. Read complete results, exit status and failure counts; investigate warnings that limit the claim.
4. Compare the evidence against each requirement and distinguish proven outcomes from untested coverage.
5. Report the verified status with supporting commands or observations; state failures plainly instead of implying completion.

Example request

Use verification-before-completion before reporting the invoice export fixed. Reproduce the original quoted-field failure, parse the resulting CSV with an independent reader and run the project suite. Confirm the requested output file exists and contains the expected rows. Show the commands, outcomes and any untested integration boundary. A linter pass or a previous agent’s “done” message is insufficient.

Worked example

An exporter can pass unit tests while its command-line wrapper writes to the wrong path. A claim that the downloadable report is ready needs an actual generated file, a parse check and the correct delivery location. Likewise, an HTTP success response from a deployment endpoint does not prove the new content is visible on the public domain. The observation should follow the user’s requested result all the way to its boundary and avoid extending a narrow check into a broader guarantee.

What you get

A completion report backed by reproducible checks, with failures and verification limits separated from confirmed results.

How to evaluate the result

• Each claim is supported by a fresh check of the relevant final state.
• Exit codes, failures and material limitations are included accurately.
• The verification reaches the actual user outcome rather than a convenient proxy.

What you need

A way to inspect or run the relevant final artifact, an explicit success criterion and access to required environments. Some outcomes require browser, device or production readback beyond local tests.

Setup and activation

The publisher documents separate installation routes for Claude Code, Codex App and CLI, Cursor and other harnesses. Use the README for your exact client; installing the whole Superpowers framework can activate additional workflows automatically. Preserve this skill’s companion files and relative references. Review and security-scan the exact selected version before installation. This directory only reviews sources; it has not installed, executed or tested this skill on those clients.

Limits and considerations

Fresh evidence can still be incomplete or based on an incorrect expectation. A green suite does not prove all requirements, security or real-world behavior. Destructive fault injection and production actions still require proper authorization. The source’s strict wording should encourage honest scope, not repeatedly rerunning unchanged checks without adding evidence.

Related workflows

• Use test-driven-development to establish a meaningful failure before a fix.
• Use finishing-a-development-branch to verify integration and preserve workspace state.

License and reuse

MIT, copyright 2025 Jesse Vincent. Preserve the copyright and permission notice when redistributing substantial source portions; inspect separately supplied dependencies and assets under their own terms.

Further reading

• Reviewed skill version (immutable commit)
• Publisher setup, compatibility and telemetry notes
• Reviewed MIT license