Source: obra/superpowers · Maintainer: community: Jesse Vincent (Prime Radiant) · License: MIT · Checked: 24 October 2026
What is the verification before completion skill?
The verification before completion skill stops a coding agent from saying "done", "fixed" or "tests pass" until it has run the command that proves it and read the result. It targets one habit: the agent that reports success from memory, from a previous run, or from a subagent's word, and is wrong.
It ships in Superpowers, the open source skill library by Jesse Vincent and Prime Radiant. The skill's description reads: "Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always".
As of 24 October 2026, its skills.sh page listed about 251,000 installs (snapshot, 24 October 2026), and the three security audits shown there (Gen Agent Trust Hub, Socket and Snyk) were all Pass.
What does it do?
The folder holds one file, SKILL.md. It is built around a rule it calls the Iron Law: "NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE". The next line makes "fresh" concrete: "If you haven't run the verification command in this message, you cannot claim it passes."
Before any claim, the agent runs a five-step gate:
- Identify the command that proves the claim.
- Run the full command, fresh and complete.
- Read the full output, check the exit code, count failures.
- Verify that the output confirms the claim. If not, state the actual status with evidence.
- Only then make the claim, with the evidence.
A table in the skill lists what each kind of claim needs and what doesn't count:
| Claim | Needs | Not enough |
|---|---|---|
| Tests pass | Test output showing 0 failures | A previous run, "should pass" |
| Linter clean | Linter output with 0 errors | A partial check |
| Build succeeds | Build command exits 0 | Linter passing, logs look good |
| Bug fixed | The original symptom tested and passing | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | The test passing once |
| Agent completed | Version control diff shows the changes | The agent reporting success |
| Requirements met | A line-by-line checklist | Tests passing |
It also lists red flags that mean stop: words like "should", "probably" and "seems to", saying "Great!" or "Done!" before checking, trusting an agent's success report, and relying on partial checks. A rationalization table answers the usual excuses, such as "I'm confident" ("Confidence ≠ evidence") and "Linter passed" ("Linter ≠ compiler").
Two patterns go beyond running tests. For a regression test, the agent writes the test, runs it, reverts the fix, runs it again (it must fail), restores the fix and runs it a third time. For requirements, it re-reads the plan, builds a checklist and checks each item, instead of treating green tests as proof the task is finished.
How do you install the verification before completion skill?
As part of Superpowers in Claude Code. The Superpowers README installs it from Anthropic's official marketplace:
/plugin install superpowers@claude-plugins-official
Plugin skills are namespaced as /plugin-name:skill-name per the Claude Code skills docs, so it appears as /superpowers:verification-before-completion. The README also covers a second Claude Code route through obra/superpowers-marketplace and installs for Codex, Cursor, Gemini CLI and other agents.
Just this skill. The skills CLI copies one folder, as shown on the skills.sh page:
npx skills add https://github.com/obra/superpowers --skill verification-before-completion
Add -g to install for all projects. The folder lands in .claude/skills/verification-before-completion/ in your project, or ~/.claude/skills/verification-before-completion/ with -g. Codex and Cursor read the same SKILL.md format; see Codex skills and Cursor skills.
How does it fit with the other Superpowers skills?
Several Superpowers skills hand off to it rather than repeat its rules:
- Systematic debugging tells the agent to use it before claiming a fix worked.
executing-plansnames it as a required sub-skill that governs the claim that a task is complete.writing-skillsuses it as an example of a discipline skill, the kind that needs testing under pressure.
It pairs naturally with test-driven development. TDD makes the agent see a test fail before it writes code; this skill makes it see the test pass, freshly, before it reports. The Superpowers README lists "Evidence over claims" among the project's principles, and this is the skill that enforces it.
It is also easy to adopt on its own: one file, no dependencies, and it applies to every task, not just the ones that run through a Superpowers plan.
How do you use it?
Mostly you don't call it. Because the description fires whenever the agent is about to claim success or commit, it can load at the end of almost any task. You can also name it when you want proof.
Example prompts (suggestions, not quotes from the repo):
Before you tell me it's done, verify: run the full test suite and the build, and paste the summary lines./superpowers:verification-before-completion The subagent says the migration is finished. Check the diff and the tests.You said the login bug is fixed. Reproduce the original steps and show me it passes now.Go back through the plan and check every requirement against the code, not just the tests.
Requirements: something to verify with, such as your test runner, linter, type checker or build command. There are no packages, scripts or API keys.
Tips and limits
From the files, not from testing:
- It can only run what exists. If your project has no tests or build step, the agent has nothing to cite. Tell it which commands count as proof, for example in your
CLAUDE.mdorAGENTS.md. - Expect longer final messages. The skill wants evidence attached to claims, so reports include command output or counts. That is the point.
- Full runs cost time. The gate asks for the full command, not a partial check. On a slow suite, say which subset is acceptable for intermediate steps.
- It is strict by design. "No exceptions" and "Spirit over letter" are in the text. Superpowers says your own instructions take precedence over its skills, so you can relax it for throwaway work.
- Nothing runs on its own. There are no bundled scripts; the agent runs your project's commands through its normal permissions.
- License. Superpowers is MIT, so you can copy and edit the skill if you keep the copyright notice.
Save it in your Kipt library
In Kipt, open Skills and paste the skill's GitHub folder link into the import box. Kipt reads the SKILL.md; for a repo with many skills it shows a list to pick from, so you can take systematic-debugging and using-git-worktrees in the same import. You can also drop the folder or a .zip. Your skills live in your own private GitHub repo and install into Claude Code or Codex with one command:
npx skills add https://github.com/<you>/<repo>.git --all -g
Kipt is not affiliated with Jesse Vincent, Prime Radiant or Superpowers.
Similar skills
- Systematic debugging skill: root cause first, then hands off to this skill before claiming the fix.
- TDD skill: Matt Pocock's red-green loop, the test-first half of the same habit.
- Receiving code review skill: verify review feedback against the code before acting on it.
- Git worktrees skill: starts work on a clean branch with a passing test baseline.