verification-before-completion
Use when about to claim work is complete, fixed, passing, or ready to integrate. Do NOT use to repeat checks without a completion claim or concrete doubt.
- License 许可
- MIT
- 最近更新
- 2026-10-14
- Stars
- ★ 16
- Forks
- 5
01 前言 Front Matter
- name
- verification-before-completion
- version
- 6.2.0
- category
- workflow
- description
- Use when about to claim work is complete, fixed, passing, or ready to integrate. Do NOT use to repeat checks without a completion claim or concrete doubt.
02 资源文件 1
- 参考文档CHANGELOG.md311 B
03 SKILL.md 正文
Verification Before Completion
Claims require fresh evidence from the current state.
Read ../using-superpowers/references/risk-policy.md.
Gate
Before a completion claim:
- Identify the observable claim.
- Choose the smallest command or manual path that proves it at the relevant boundary.
- Run it fresh.
- Read the result and exit status.
- Report the evidence and any unverified boundary.
The complete command means the complete chosen check, not the entire repository suite. Verification scope follows risk.
Examples
| Claim | Evidence |
|---|---|
| Focused behavior works | affected test or reproducible smoke path |
| Build succeeds | build command exits 0 |
| Bug is fixed | original reproduction no longer fails |
| Plugin is installed | plugin listing shows expected source and version |
| Requirements are met | final diff checked against the approved scope |
Do not substitute old output, a reviewer summary, lint for a build, or tests for an untested user-visible boundary.
Limits
- Run the affected check once after the final relevant change.
- Rerun only when the checked state changed or the first result was ambiguous.
- Run the full suite only for shared core, a release boundary, or an explicit request.
- Do not make a reviewer repeat checks already evidenced without a concrete doubt.
If verification fails, report the actual state. Do not soften it into a success claim.
04 同仓库更多 Skills
bad
暂无简介
writing-skills
Use when creating, editing, or validating reusable agent skills and their trigger behavior. Do NOT use for ordinary project documentation or one-off prompts.
writing-plans
Use when an approved change spans multiple dependent outcomes and needs a durable implementation sequence before coding. Do NOT use for small, obvious, reversible edits.
using-superpowers
Use when starting a conversation or deciding whether a Superpowers workflow matches the current task. Do NOT use it to auto-invoke skills whose stated triggers do not match.
using-git-worktrees
Use when feature work needs isolation from the current workspace or before executing a risky implementation plan. Do NOT use when the current workspace is already safe and isolated.
test-driven-development
Use when implementing a high-risk behavior change, reproduced regression, or costly contract. Do NOT use by default for docs, styling, config, or low-risk wiring.