Use when implementation is complete, all tests pass, and you need to decide how to integrate the work — guides completion of development work by presenting structured options for merge, PR, or cleanup
日本語の概要は準備中です。原文の説明を表示しています。
Use when about to claim work is complete, fixed, or passing; run verification and read the output before any success claim.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Evidence before claims. Run the command, read the output, THEN claim the result. No shortcuts. No "should work." No exceptions.
$codex-verification-discipline, $verify, or $evidence.Announce at start: "I'm verifying before claiming completion."
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this message, you cannot claim it passes.
Violating the letter of this rule is violating the spirit of this rule.
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 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 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 |
If you catch yourself thinking or writing:
| 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 |
| "Partial check is enough" | Partial proves nothing |
| "Different words so rule doesn't apply" | Spirit over letter |
| "It's trivial" | Trivial things break. Run it. |
Tests:
✅ [Run test command] → [See: 34/34 pass] → "All tests pass"
❌ "Should pass now" / "Looks correct"
Regression tests (TDD Red-Green):
✅ Write → Run (FAIL) → Implement → Run (PASS) → "Regression test verified"
❌ "I've written a regression test" (without red-green verification)
Build:
✅ [Run build] → [See: exit 0] → "Build passes"
❌ "Linter passed" (linter ≠ build)
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
Agent delegation:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
ALWAYS before:
| Skill | How Verification Integrates |
|---|---|
codex-test-driven-development | Verify RED and GREEN steps with actual test output |
codex-execution-quality-gate | Gate scripts provide the evidence; this skill ensures you actually READ the output |
codex-systematic-debugging | Verify root cause fix with regression test evidence |
codex-subagent-execution | Verify subagent output with VCS diff, not agent reports |
codex-branch-finisher | Verify tests before presenting completion options |
--help first.No shortcuts for verification.
Run the command. Read the output. THEN claim the result.
This is non-negotiable.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work — guides completion of development work by presenting structured options for merge, PR, or cleanup
日本語の概要は準備中です。原文の説明を表示しています。
Use when a project has 50+ files, missing context, or explicit $codex-genome request; generates multi-layer project context to reduce hallucination.
日本語の概要は準備中です。原文の説明を表示しています。
Use for DESIGN.md visual identity contracts; author, scaffold, lint, diff, and export design contracts with the upstream spec and CLI.
日本語の概要は準備中です。原文の説明を表示しています。
Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks.
日本語の概要は準備中です。原文の説明を表示しています。
Use when code changes may require documentation updates; maps git diff to candidate docs without auto-editing documentation.
日本語の概要は準備中です。原文の説明を表示しています。
Use for documents, reports, memos, guides, academic papers, or formal text that needs clear structure, reliable tone, formatting, and diagrams.
日本語の概要は準備中です。原文の説明を表示しています。