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.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
中文简介正在准备中。当前显示原文说明。