Verification before completion
Skill gustavo-meilus/superpipelines/plugins/superpipelines/skills/verification-before-completion
Enforces the Iron Law — no completion claim without fresh verification evidence. Use when an agent is about to claim work is complete, a bug is fixed, or a system state is passing; before committing changes or opening PRs; or after receiving a subagent DONE report that has not been independently verified.From its SKILL.md
npx -y skills add gustavo-meilus/superpipelines --skill verification-before-completionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.8 KB, 795 tokens by cl100k_base, as published. Nobody here has run it
Verification Before Completion — Success Protocol
<overview> The Iron Law: **NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**. The use of "should," "probably," or "seems to" in status assertions is prohibited. Success is a documented, reproducible fact — not an assumption. </overview> <glossary> <term name="Gate Function">A mandatory five-step sequence (Identify, Run, Read, Verify, Claim) that must be completed before communicating success.</term> <term name="Evidence before Claim">The requirement to execute a verification command and analyze its output before stating a status.</term> <term name="Regression Verification">A Red-Green cycle proving that a test not only passes now but would have failed without the fix.</term> </glossary>Governs the requirement for absolute evidence before any claim of task completion, bug resolution, or system readiness.
The Success Protocol
<protocol> ### THE GATE FUNCTION 1. **IDENTIFY**: Determine exactly which command or action proves the claim. 2. **RUN**: Execute the full, fresh verification command. 3. **READ**: Analyze the complete output, check exit codes, and count failures. 4. **VERIFY**: Confirm the output matches the success criteria of the original requirement. 5. **CLAIM**: State the completion status alongside the supporting evidence.<invariant>Skip any step = failure of the verification protocol.</invariant> </protocol>
<invariants> - NEVER express satisfaction ("Great!", "Perfect!") before running verification. - NEVER trust a subagent's "DONE" report without inspecting the VCS diff and running local tests. - ALWAYS perform a Red-Green cycle for regression tests to prove the test's validity. - Linter clean state is NOT a proxy for build success or logic correctness. </invariants>Verification Patterns
<patterns> | Quality | Goal | Required Evidence | | :--- | :--- | :--- | | **Tests** | All green | Command output showing `0 failures` across the entire suite. | | **Linter** | Clean state | Command output showing `0 errors` and `0 warnings`. | | **Build** | Successful binary | Execution log showing `exit 0` and artifact generation. | | **Bug Fix** | Resolved symptom | Reproduction script passing + Red-Green verification. | | **Requirements** | Spec compliance | Line-by-line checklist verification against `spec.md`. | </patterns>Red Flags — STOP
- "It should work now." → STOP. Run the verification command.
- "I'm confident it's fixed." → STOP. Confidence is not evidence.
- "The agent said it was done." → STOP. Subagents are non-deterministic; verify independently.
- "I'll do a partial check to save time." → STOP. Partial verification proves nothing about system integration.
Rationalization Table
<rationalization_table>
| Excuse | Reality |
|---|---|
| "I manually verified it." | Manual verification is non-reproducible and prone to observation bias. |
| "It's just a small fix." | Small fixes cause the majority of production regressions. |
| "I'm tired/in a hurry." | Exhaustion increases the probability of overlooking silent failures. |
| "Spirit over ritual." | The ritual of evidence is what protects the system's integrity. |
| </rationalization_table> |
Reference Files
systematic-debugging/SKILL.md— Root cause investigation.test-driven-development/SKILL.md— Red-Green cycle rules.sk-write-review-isolation/SKILL.md— Two-stage review protocol.sk-worktree-safety/SKILL.md— Integration verification.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 3 of the 12 instructions most quality gates skills give in 795 tokens
Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06
- Read full output and check exit codein 45 of 1524, across 40 files
- Verify output confirms the claimin 44 of 1524, across 39 files
- Identify the command that proves the claimhere, and in 43 of 1524, across 39 files
- Execute the full verification commandhere, and in 36 of 1524, across 30 files
- Produce a verification reportin 34 of 1524, across 18 files
- Review git diff changesin 30 of 1524, across 16 files
- Fix build failures immediatelyin 29 of 1524, across 9 files
- Group findings by severityin 28 of 1524
- State claim only with evidencein 27 of 1524, across 22 files
- Verify regression tests with red-green cyclehere, and in 26 of 1524, across 22 files
- Run the full test suitein 26 of 1524, across 25 files
- Run test suite with coveragein 25 of 1524, across 10 files
Said here and by no other author read
- Analyze output and check exit codes
- Confirm output matches success criteria
- State completion status with supporting evidence
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.