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.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.