kiro-verify-completion
starsforks
How to install kiro-verify-completion?
gotalab/cc-sdd/kiro-verify-completion
$npx -y skills add gotalab/cc-sdd --skill kiro-verify-completionVerify completion and success claims with fresh evidence. Use before claiming a task is complete, a fix works, tests pass, or a feature is ready for GO.
SKILL.md
| 1 | # kiro-verify-completion |
| 2 | |
| 3 | <background_information> |
| 4 | This skill prevents false completion claims. A task, fix, or feature is only complete when supported by fresh evidence that matches the scope of the claim. |
| 5 | </background_information> |
| 6 | |
| 7 | <instructions> |
| 8 | ## When to Use |
| 9 | |
| 10 | - Before saying a task is complete |
| 11 | - Before saying a bug is fixed |
| 12 | - Before saying tests pass |
| 13 | - Before moving to the next task in autonomous execution |
| 14 | - Before reporting `GO` from feature-level validation |
| 15 | - Before trusting another subagent's success report |
| 16 | |
| 17 | Do not use this skill for early planning or speculative status updates. |
| 18 | |
| 19 | ## Inputs |
| 20 | |
| 21 | Provide: |
| 22 | - The exact claim to verify |
| 23 | - Claim type: |
| 24 | - `TASK` |
| 25 | - `FIX` |
| 26 | - `TEST_OR_BUILD` |
| 27 | - `FEATURE_GO` |
| 28 | - Validation commands discovered by the controller |
| 29 | - Fresh command output and exit codes |
| 30 | - Relevant task IDs, requirement IDs, and design refs where applicable |
| 31 | - For feature-level claims: |
| 32 | - requirements coverage status |
| 33 | - design alignment status |
| 34 | - integration status |
| 35 | - blocked task status |
| 36 | |
| 37 | ## Outputs |
| 38 | |
| 39 | Return one of: |
| 40 | - `VERIFIED` |
| 41 | - `NOT_VERIFIED` |
| 42 | - `MANUAL_VERIFY_REQUIRED` |
| 43 | |
| 44 | Also return: |
| 45 | - Claim reviewed |
| 46 | - Evidence used |
| 47 | - Scope/evidence mismatch, if any |
| 48 | |
| 49 | Use the language specified in `spec.json`. |
| 50 | |
| 51 | ## Gate Function |
| 52 | |
| 53 | 1. Identify the exact claim. |
| 54 | 2. Identify the exact command or checklist that proves that claim. |
| 55 | 3. Require fresh evidence from the current code state. |
| 56 | 4. Check exit code, failure count, skipped scope, and missing coverage. |
| 57 | 5. Reject claims that are broader than the evidence. |
| 58 | 6. If mandatory validation cannot be completed, return `MANUAL_VERIFY_REQUIRED`. |
| 59 | 7. Only then allow the claim. |
| 60 | |
| 61 | ## Claim-Specific Rules |
| 62 | |
| 63 | ### TASK |
| 64 | Require: |
| 65 | - task-local verification evidence |
| 66 | - no unresolved blocking findings from review |
| 67 | - evidence aligned with the task boundary |
| 68 | |
| 69 | ### FIX |
| 70 | Require: |
| 71 | - evidence that the original symptom is resolved |
| 72 | - no broader regressions in the relevant verification scope |
| 73 | |
| 74 | ### TEST_OR_BUILD |
| 75 | Require: |
| 76 | - actual command output |
| 77 | - exit code |
| 78 | - no inference from unrelated checks |
| 79 | |
| 80 | ### FEATURE_GO |
| 81 | Require: |
| 82 | - full test suite result |
| 83 | - runtime smoke boot result showing the built artifact reaches its first usable state |
| 84 | - requirements coverage assessment |
| 85 | - cross-task integration assessment |
| 86 | - design end-to-end alignment assessment |
| 87 | - blocked tasks assessment |
| 88 | |
| 89 | A passing test suite alone is not enough for `FEATURE_GO`. |
| 90 | |
| 91 | ## Stop / Escalate |
| 92 | |
| 93 | Return `MANUAL_VERIFY_REQUIRED` when: |
| 94 | - No canonical validation command is known |
| 95 | - The required environment is unavailable |
| 96 | - A mandatory manual verification step cannot be executed |
| 97 | |
| 98 | Return `NOT_VERIFIED` when: |
| 99 | - The command failed |
| 100 | - Evidence is stale |
| 101 | - Evidence is partial |
| 102 | - The claim exceeds the evidence |
| 103 | - The feature still has unresolved blocked tasks or uncovered requirements |
| 104 | |
| 105 | ## Common Rationalizations |
| 106 | |
| 107 | | Rationalization | Reality | |
| 108 | |---|---| |
| 109 | | “The subagent said it succeeded” | Reported success is not verification evidence. | |
| 110 | | “Tests passed earlier” | Fresh evidence only. | |
| 111 | | “Build should be fine because lint passed” | Lint does not prove build success. | |
| 112 | | “Tests passed and build succeeded, so it must run” | Type erasure, module loading, native ABI, and boot-time config issues can still fail at runtime. | |
| 113 | | “The feature is done because all tasks are checked off” | `FEATURE_GO` also requires coverage, integration, and design alignment. | |
| 114 | |
| 115 | ## Output Format |
| 116 | |
| 117 | ```md |
| 118 | ## Verification Result |
| 119 | - STATUS: VERIFIED | NOT_VERIFIED | MANUAL_VERIFY_REQUIRED |
| 120 | - CLAIM_TYPE: TASK | FIX | TEST_OR_BUILD | FEATURE_GO |
| 121 | - CLAIM: <exact claim> |
| 122 | - EVIDENCE: <command/checklist and result> |
| 123 | - GAPS: <scope/evidence mismatch or missing validation> |
| 124 | - NOTES: <next action if not verified> |
| 125 | ``` |
| 126 | </instructions> |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse 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; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
