メニュー
Use before claiming any task is complete, fixed, or passing. Enforces evidence-based completion — no claims without fresh verification. Applies to tests, builds, bug fixes, and requirement fulfillment.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | verify |
| description | Use before claiming any task is complete, fixed, or passing. Enforces evidence-based completion — no claims without fresh verification. Applies to tests, builds, bug fixes, and requirement fulfillment. |
| argument-hint | [what you're about to verify] |
"Claiming work is complete without verification is dishonesty, not efficiency."
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this message, you cannot claim it passes.
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" |
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Requirements met | Line-by-line checklist | Tests passing |
Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
A regression test that never failed is not a regression test.
/tdd to confirm implementation/diagnose to confirm fix/handoff to ensure clean stateFind deepening opportunities in a codebase — refactors that turn shallow modules into deep ones. Use when the codebase feels hard to change, bugs cluster in certain modules, adding features requires touching many files, or proactively every few days as a health check.
Collaborative design exploration before implementation. Use when starting a new feature or project, when the approach is unclear, or when multiple design directions exist. Unlike /grill (which aligns on a given plan), /brainstorm explores and creates the plan. Enforces a HARD-GATE: no code until design is approved.
Systematic debugging loop for hard bugs and performance regressions. Use when something is broken and you don't know why, when behavior is inconsistent, or when error messages are unclear. Follows reproduce → minimise → hypothesise → instrument → fix → regression-test.
Deep alignment session before coding. Use when starting a non-trivial feature, when requirements are ambiguous, before refactoring, or when the user's request could be interpreted multiple ways. Surfaces assumptions, presents tradeoffs, and produces a verified implementation plan.
Request and handle code reviews with technical rigor. Use after completing a feature or task, before merging. Covers both requesting reviews and responding to feedback — verify before implementing, push back when wrong, no performative agreement.
Test-driven development with red-green-refactor loop. Use when building features, fixing bugs, refactoring code, or when the user mentions TDD, test-first, or red-green-refactor. Builds one vertical slice at a time.