菜单
Use 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. 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, or passing, before committing or creating PRs. 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 message, you cannot claim it passes.
MANDATORY: Before any verification, discover what this project uses. Do not invent generic commands — use what the project defines.
Task runners (check for these files in the project root):
justfile / .justfile — run just --list to see available recipesMakefile — run make help or scan targets with grep '^[a-zA-Z]' Makefilepackage.json — check scripts section: cat package.json | jq .scriptsCI workflows — the most authoritative source of what "passing" means:
.github/workflows/ — what does the CI run on PRs?.gitlab-ci.yml, .circleci/config.yml, JenkinsfileCI workflow steps > justfile/Makefile targets > package.json scripts > raw commands
Using raw commands (go test ./..., npm test) when a project defines
just test or make test is a verification failure —
the project wrapper may set required flags, env vars, or run additional checks.
BEFORE claiming any status or expressing satisfaction:
Skip any step = lying, not verifying
| Claim | Requires | Not Sufficient |
|---|---|---|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | Test passes once |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler |
| "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 |
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
From 24 failure memories:
ALWAYS before:
Rule applies to:
No shortcuts for verification.
Run the command. Read the output. THEN claim the result.
This is non-negotiable.
Use when starting feature work that needs isolation from current workspace, before executing implementation plans, or when reviewing an existing branch (e.g. a PR) without switching away from the current branch. It creates isolated git worktrees under `.worktrees/`.
Use this skill when working on terminal UI rendering, interactive CLI prompts, ANSI color output, terminal screenshots, Bubble Tea/Lip Gloss/Huh/Glamour, curses-style apps, or CLI tests that depend on TTY behavior.
Use this skill when you're working with golang code.
Use whenever asked to create GitHub Pull Request.
Use when writing, rewriting, or updating a pull request description. Use this skill's explicit PR template unless the user provides a different template for the current task, keep the result concise and human-readable, explain why the change exists, and ask the user for motivation before updating the PR when the user has not explicitly provided it.
Use this skill whenever writing, editing, reviewing, or deciding whether to add code comments, docstrings, inline comments, or internal function documentation in any programming language. Use it even when the task only mentions "comments", "docs in code", "docstrings", "document this function", or "explain this helper".