verification-before-completion
Run verification commands and confirm output before claiming success. Use when about to claim work is complete, fixed, or passing, before committing or creating PRs.
52
57%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/verification-before-completion/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.
The description has good structural completeness with clear 'what' and 'when' clauses, which is its strongest aspect. However, it lacks specificity in the concrete actions it performs (what verification commands?) and the trigger terms lean toward internal workflow states rather than natural user language. It would benefit from listing specific verification actions and more natural trigger terms.
Suggestions
Add specific concrete actions like 'run tests, lint code, type-check, build project' instead of the vague 'run verification commands'.
Include more natural user-facing trigger terms such as 'tests', 'build', 'lint', 'CI', 'check if it works', 'verify changes'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names a domain (verification before claiming success) and a general action ('run verification commands and confirm output'), but doesn't list specific concrete actions like 'run tests', 'lint code', 'type-check', 'build project'. The actions remain somewhat abstract. | 2 / 3 |
Completeness | Clearly answers both what ('Run verification commands and confirm output before claiming success') and when ('Use when about to claim work is complete, fixed, or passing, before committing or creating PRs') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'committing', 'creating PRs', 'fixed', 'passing', 'complete', but misses natural user phrases like 'run tests', 'check if it works', 'verify build', 'CI', 'lint'. The triggers are more about Claude's internal workflow than user-facing language. | 2 / 3 |
Distinctiveness Conflict Risk | The concept of 'verification before completion' is somewhat distinct, but 'run verification commands' could overlap with testing skills, CI/CD skills, or code review skills. The scope is broad enough to potentially conflict with more specific verification-related skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
47%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill has a clear and important purpose—ensuring verification before completion claims—and provides a well-structured workflow with concrete commands. However, it is severely undermined by extreme verbosity and repetition; the core message could be conveyed in roughly one-third the tokens. The motivational/admonishment tone ('lying', 'you'll be replaced', 'non-negotiable') adds bulk without adding actionable value, and much of the content reinforces behaviors Claude already has.
Suggestions
Reduce content by ~60%: merge the 'Red Flags', 'Rationalization Prevention', and 'Why This Matters' sections into a single brief 'Anti-patterns' section, eliminating redundant restatements of the core principle.
Remove motivational/philosophical framing ('Iron Law', 'The Bottom Line', 'This is non-negotiable', 'Honesty is a core value') — Claude already knows these concepts and the tokens are wasted on reinforcement.
Consolidate the Common Failures table and Key Patterns section into a single reference, as they largely overlap in content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose and repetitive. The same point ('verify before claiming') is restated in at least 8 different ways across multiple sections. The 'Rationalization Prevention' table, 'Red Flags', and 'Why This Matters' sections all repeat the same core message. Much of this content (honesty, not trusting assumptions) is already core to Claude's behavior and doesn't need extensive reinforcement. The motivational/philosophical framing ('Iron Law', 'The Bottom Line', 'This is non-negotiable') wastes tokens. | 1 / 3 |
Actionability | The Gate Function provides a clear 5-step process, and concrete verification commands (bun test, npm run build, etc.) are provided. However, the skill is more about behavioral reinforcement than executable guidance. The commands listed are generic and obvious; the real content is admonishment rather than actionable instruction. The key patterns section with ✅/❌ examples adds some concrete guidance. | 2 / 3 |
Workflow Clarity | The Gate Function provides a clear sequential workflow with an explicit validation checkpoint (step 4's if/then branching). The regression test pattern shows a proper red-green cycle. The Common Failures table clearly maps claims to required evidence. For this type of behavioral/process skill, the workflow is well-defined with feedback loops. | 3 / 3 |
Progressive Disclosure | The content is organized into logical sections with headers, but it's a monolithic document that could benefit from being more concise rather than split. No bundle files exist, which is fine for this skill's scope, but the sheer volume of inline content (tables, examples, rationalization prevention) makes it feel like a wall of text that could be significantly trimmed rather than needing separate files. | 2 / 3 |
Total | 8 / 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
- secondsky/claude-skills
- Commit
5e92b71
- 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.