メニュー
Use when about to claim work is complete, fixed, passing, or done. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | verification-before-completion |
| description | Use when about to claim work is complete, fixed, passing, or done. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always. |
Claiming work is complete without verification is dishonesty, not efficiency.
Core principle: Evidence before claims, always.
Violating the letter of this rule is violating the spirit of this rule.
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this response, you cannot claim it passes.
Always — before ANY of these claims:
This skill has no exceptions. If you're about to claim something is done, use this skill.
YOU CANNOT:
- Say "should work" — run it and show the output
- Say "tests pass" without test output in this response — stale evidence is not evidence
- Say "build succeeds" because "linter passed" — they're different things
- Trust a sub-agent's success claim — verify independently
- Use "looks good" as verification — what command proves it?
- Claim "done" based on mental reasoning — evidence is output, not thought
- Skip full test suite because "only this file changed" — regressions are unexpected
- Express satisfaction ("Great!", "Perfect!") before verification — verify, then celebrate
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler ≠ tests |
| "Agent said success" | Verify independently |
| "I'm tired" | Exhaustion ≠ excuse |
| "Partial check is enough" | Partial proves nothing |
| "Different words, so rule doesn't apply" | Spirit over letter |
| "I checked mentally" | Mental checks aren't evidence |
| "It's a trivial change" | Trivial changes cause most outages |
1. What COMMAND proves this claim? (name the exact command)
2. Have I run that command in THIS response? (not earlier, not "just now")
3. Does the output ACTUALLY confirm the claim? (read the output — don't skim)
4. Did I check the EXIT CODE? (0 = success, not always)
5. Are there any WARNINGS I'm ignoring? (warnings often become errors)
6. Did I run the FULL relevant suite? (not just one test)
7. Am I claiming more than the evidence shows? ("tests pass" vs "these 3 tests pass")
8. Would I bet money on this claim based on this evidence? (if not, gather more)
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output — check exit code, count failures
4. VERIFY: Does output actually confirm the claim?
- If NO → State actual status with evidence
- If YES → State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying.
| Claim | Requires | Not Sufficient |
|---|---|---|
| "Tests pass" | Test output: 0 failures, all pass | Previous run, "should pass" |
| "Build succeeds" | Build output: exit 0 | "Linter passed" |
| "Linter clean" | Linter output: 0 errors, 0 warnings | Partial check |
| "Bug fixed" | Reproduction test passes + no regressions | "Code changed" |
| "Type-safe" | Type checker output: 0 errors | "No red squiggles" |
| "Feature complete" | Line-by-line requirement check + all tests | "Tests pass" |
| "No regressions" | Full suite green | Targeted tests only |
| "Agent completed" | VCS diff of actual changes | Agent's "success" claim |
| "Deployed" | Health check returns 200 + metrics stable | Deploy command exit 0 |
| "Performance improved" | Before/after benchmarks | "Feels faster" |
| "Security fixed" | Vulnerability scan passes | "Patched the code" |
✅ [Run test command] → [Output shows: 34/34 pass] → "All 34 tests pass"
❌ "Should pass now"
❌ "Tests look correct"
✅ Write test → Run (FAIL) → Fix → Run (PASS) → Revert fix → Run (FAIL) → Restore → Run (PASS)
❌ "I wrote a regression test" (without red-green cycle)
✅ [Run build] → [Output shows: exit 0, no errors] → "Build passes"
❌ "Linter passed, so build should be fine"
✅ Re-read plan → Create checklist → Verify each item with evidence → Report gaps or completion
❌ "Tests pass, so feature is complete"
✅ Deploy → Health check → Metrics stable for 15min → Error rate baseline → "Deployed successfully"
❌ "Deploy command succeeded"
You are about to violate this rule if:
executing-plans tasksystematic-debugging fixgit-workflow mergecode-review findingsincident-responseUse when porting any module from a Next.js (React) app to a Nuxt 4 (Vue 3) production app backed by NestJS. User provides module name and three repo paths. Covers submodule analysis, backend verification, feature inventory, sidebar registration, theme/dark-mode rules, and multi-pass execution.
Use as the master reference for all core principles, anti-hallucination protocol, severity framework, and skill activation rules. Every other skill inherits from this. Read this first in any new session.
Use when creating new skills for the skills library. Defines the structure, format, quality standards, and testing requirements for new skills.
Multi-agent council using real subagent spawning (Task() tool), deterministic CLI state management, and file-based handoffs. Orchestrator stays lean while specialists execute in fresh contexts.
Use when you have a spec or requirements for a multi-step task and need to create a detailed implementation plan before touching code.
Use when you have a detailed implementation plan and need to execute it task by task with deviation handling, checkpoints, and atomic commits.