There is a practical difference between believing a change works and having evidence that supports the claim. This skill is useful immediately before reporting a fix, successful tests, or readiness for handoff.
Install and start
Run the following plugin command inside a Claude Code session to install Superpowers, including its cooperating skills. In Codex, find Superpowers in the plugin interface and install it there. Install separately for each client you use. Start a fresh session in the project and explicitly ask to use verification-before-completion with a bounded task.
/plugin install superpowers@claude-plugins-official
Identify what must be established
Adapt this first request to your project:
Use Superpowers verification-before-completion on the order-export changes. Derive the required claims from the requirements, select existing tests, type checks, and build commands, then run and inspect them. Report results and unverified scope. Do not treat another agent's completion report as test evidence.
Generating an export file, rejecting unauthorized users, and completing a build are different claims. They may need different checks. A passing linter cannot establish all three. Select necessary evidence from the requirements and actual changes rather than running an unrelated collection of commands for appearances.
Inspect fresh, complete results
Checks should run against the current code, not a previous revision's logs. Read the exit status, failures, and full relevant output. A green final line or abbreviated excerpt may omit an earlier problem. A command that is still running has not yet produced a successful result.
For a defect fix, confirm that the regression test detects the original condition. For a feature, check requirements individually, including permissions, boundary inputs, and failure paths. Another agent's completion message is useful progress information, but it does not replace reviewing the diff and obtaining verifiable execution results.
Choose evidence that fits the change. Type checking cannot observe a hidden focus target or a misplaced error message in a browser. A database migration that succeeds on empty tables may not establish compatibility with existing data. Add interaction or representative-data checks where they answer a material question.
Report both results and scope
A concise handoff can state what was checked, the observed result, and what that check covers. If a local service or credential is missing, identify the unmet condition and the behavior still unverified. Do not translate an absence of observed errors into a blanket pass. Separate pre-existing failures from regressions caused by the current change.
The purpose is not to keep adding tests indefinitely. When the appropriate checks pass and no unresolved concern remains, finish with a claim proportionate to the evidence. The skill cannot guarantee that no defect was overlooked, but it helps prevent assumptions, stale logs, or secondhand reports from being presented as completed verification. That makes the final handoff easier to trust and easier to continue later.
Verify a database migration with matching evidence
If a change adds a non-null status column to the users table, a successful migration on an empty database proves only the empty path. Also prepare a database with old users, run the migration, and inspect defaults on old rows, read/write paths, and recovery options. Passing an API test does not show that background jobs or reports handle the new field; list each claim and its matching check. If production data cannot be copied, explain what an anonymized sample can and cannot prove.
Report only established scope: “migration succeeded on a test database with 500 old records” and “new registration and old-user login checks passed.” Do not collapse those into “migration is completely safe.” List unrun commands, still-running builds, and failures separately. Screenshots and agent summaries may suggest what to inspect but cannot replace fresh exit codes, logs, and data checks. After changing code to fix a discovered problem, rerun the affected checks; an earlier green result is stale.
Check where the evidence came from
Running a check is not enough; establish who produced its output. In one debugging session, a manually invoked probe wrote a log entry that was mistaken for an automatically triggered system hook. Later, an empty log was mistaken for proof that the hook never fired. To verify a hook, give the manual probe and real trigger distinct markers, then record the trigger action, time, process, and output path. If the evidence cannot distinguish them, report only that the probe can write a log, not that the business hook ran. The same discipline applies to payment callbacks, background jobs, and deployments.