verification-before-completion
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
80
72%
Does it follow best practices?
Impact
92%
1.22xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/verification-before-completion/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description effectively communicates when it should be triggered with an explicit 'Use when' clause and covers the behavioral intent well. However, it lacks specificity about what concrete verification actions should be taken (e.g., running tests, linting, building) and uses somewhat generic language like 'verification commands'. The tagline 'evidence before assertions always' is a nice principle but adds more of a motto than actionable detail.
Suggestions
Add specific concrete actions like 'run tests, check linting, build the project, verify type checks' instead of the vague 'running verification commands'.
Include more natural trigger terms users might say, such as 'done', 'finished', 'ready to merge', 'all tests pass', 'bug is fixed' to improve matching.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a domain (verification before claiming completion) and some actions ('running verification commands and confirming output'), but doesn't list specific concrete actions like 'run tests', 'check linting', 'build project', or 'run type checks'. | 2 / 3 |
Completeness | Clearly answers both 'what' (requires running verification commands and confirming output before making success claims) and 'when' (when about to claim work is complete, fixed, or passing, before committing or creating PRs). The 'Use when' clause is explicit. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'complete', 'fixed', 'passing', 'committing', 'creating PRs', but misses common natural user phrases. This skill is more of a behavioral guardrail than something a user triggers directly, making trigger terms less applicable but still somewhat present. | 2 / 3 |
Distinctiveness Conflict Risk | The concept of 'verification before completion' is somewhat distinct, but 'running verification commands' and 'committing or creating PRs' could overlap with git workflow skills, CI/CD skills, or testing skills. The behavioral/meta nature helps distinguish it somewhat. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong behavioral skill that clearly defines when and how to verify work before claiming completion. Its greatest strengths are the concrete Gate Function workflow, the excellent Common Failures mapping table, and the clear ✅/❌ pattern examples. The main weakness is moderate redundancy across sections (Red Flags, Rationalization Prevention, and The Bottom Line all reinforce the same message) which could be consolidated for better token efficiency.
Suggestions
Consolidate the 'Red Flags' and 'Rationalization Prevention' sections into a single table to reduce redundancy and improve token efficiency.
Consider moving the 'Why This Matters' section (failure memories) to a separate reference file, as it provides motivation rather than actionable guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but has some redundancy - the 'Rationalization Prevention' table largely restates the 'Red Flags' section, and the motivational framing ('dishonesty, not efficiency', 'lying, not verifying') adds emotional weight but not actionable information. The tables are well-structured but could be tighter. | 2 / 3 |
Actionability | The Gate Function provides a clear, concrete 5-step process. The Common Failures table maps specific claims to specific verification requirements. The Key Patterns section shows exact ✅/❌ examples with concrete verification patterns (run command, check output, then claim). This is highly actionable guidance. | 3 / 3 |
Workflow Clarity | The Gate Function is an explicit, sequenced workflow with validation checkpoints (step 4's YES/NO branching). The regression test pattern shows a complete red-green feedback loop. The 'When To Apply' section clearly defines trigger conditions. Verification is the entire point of this skill and it's thoroughly covered. | 3 / 3 |
Progressive Disclosure | The content is well-organized with clear sections and tables, but it's a fairly long single document (~100+ lines of content) with no references to external files. Some sections like the detailed failure memories context or the rationalization table could be split out. However, for a behavioral/process skill this length is borderline acceptable. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- obra/superpowers
- Commit
b7a8f76
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.