From team-shinchan
Enforces a verification gate before claiming task completion, requiring command execution, output capture, and pass/fail verdict. Useful for preventing unverified completion claims.
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-shinchan:verification-before-completionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Never claim a task is complete without running a verification command and reading its output. "I believe it works" is not evidence.
Never claim a task is complete without running a verification command and reading its output. "I believe it works" is not evidence.
You MUST verify at each of these triggers:
Every completion claim must include:
If you cannot provide all three, you have NOT verified. Go back and run the command.
If your completion report contains ANY of these phrases, you have NOT verified -- STOP and actually run a command:
| Red Flag Phrase | What To Do Instead |
|---|---|
| "should work" | Run the test and show it passes |
| "probably fine" | Run the linter/build and show zero errors |
| "seems to" | Read the actual output and report what it says |
| "looks correct" | Run a validator or test that proves correctness |
| "I believe" | Replace belief with evidence -- run a command |
| "likely" | Remove doubt -- execute and observe |
| "I think" | Verify instead of thinking |
| "no issues expected" | Prove it -- run the check |
Use this format in your completion report:
### Verification
- **Command**: `node tests/validate/index.js`
- **Expected**: All validators pass, 0 errors
- **Actual**: 23 validators passed, 0 errors, 0 warnings
- **Verdict**: PASS
If the verdict is FAIL, fix the issue before claiming completion. Do not report a task as done with a FAIL verdict.
Gate-enforced (glucofit / main-075 adoption). At Stage 4, this
## Verificationsection (inIMPLEMENTATION.md, or a standaloneVERIFICATION.md) carrying aVerdict: PASSis now a hard prerequisite forstatus: completed—hooks/transition-gate.shblocks completion without it. One row per REQUESTS.md acceptance criterion, exercised against REAL behavior (the built-inverify/runskill for runnable surfaces; the AC check command for non-runnable ones). AnUNVERIFIEDAC blocks completion. This closes the "구현 다 하고 QA하면 엉망" hole where self-graded checklists passed as done.
At the before-PR and before-completion checkpoints, an APPROVED fierce-review artifact satisfies the code-review evidence requirement (it is a schema-validated, adversarially-verified rubric pass — stronger than a single read-through). If .shinchan-docs/reviews/REVIEW-{NNN}.json exists for the current scope with verdict.verdict == "APPROVED" and an empty must_fix, cite it:
/team-shinchan:fierce-review <scope>.shinchan-docs/reviews/REVIEW-{NNN}.jsonA REJECTED artifact, a non-empty must_fix, or a stale one (scope no longer matches the current diff) is NOT evidence — re-run the review. This does not replace the test/build evidence above; it adds the review dimension.
Completion/verification MAY additionally require a typed evidence receipt — a machine-rejectable record proving the right kind of evidence exists for the surface that changed. This is a conceptual port (MIT↔MIT) of an ultragoal-style completion gate: prose claims ("it works", "looks correct") are insufficient; the receipt is validated by src/evidence-receipt.js. This is additive guidance, not a hard mandatory gate — the existing exit-0 verify gate (src/dag-executor.js) keeps working unchanged. Adopt receipts where stronger, surface-specific proof is warranted (e.g. GUI work where an exit code alone proves little).
Carrier: the natural carrier is the same .shinchan-docs/reviews/REVIEW-{NNN}.json artifact used above — embed the receipt object under a receipt key.
Surface taxonomy (WS-06) — each surface demands a different machine-checkable evidence shape (validateEvidenceReceipt rejects with a specific reason per failed rule):
surface | Required surfaceEvidence / refs |
|---|---|
gui | { automationTranscript, screenshotRef } |
cli | { replaySafe: true, command, recordedStdout } |
native | { ptyCaptureRef } or { screenshotRef } |
api | at least one artifactRefs[] entry |
math | at least one artifactRefs[] entry |
A complete receipt also needs contractCoverage (a number in [0,1]) and a non-empty adversarialCases array (at least one adversarial/red-team case) — a "complete" verdict requires proof the work survives hostile input, not just the happy path.
Freshness-scoping: receipts carry a scope hash. isReceiptFresh(receipt, currentScopeHash) returns false when the goal/spec changed (receipt.scope !== currentScopeHash) — stale evidence is NOT evidence. Re-capture the receipt when scope moves.
Integration point: a gate that wants this stronger proof can call validateEvidenceReceipt(receipt) and isReceiptFresh(receipt, scopeHash) and treat { valid:false } or a stale receipt the same way it treats a REJECTED review — block until re-captured. Wiring this into src/dag-executor.js's completion gate is OPTIONAL and must remain backward-compatible (receipt absent ⇒ fall back to the existing exit-0 verify gate).
npx claudepluginhub seokan-jeong/team-shinchan --plugin team-shinchanGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.