Starter: interpret a council run's verdict artifacts — quorum, dissent, cross-lab validity, and what to do next
日本語の概要は準備中です。原文の説明を表示しています。
Use when about to declare work complete, fixed, passing, or done
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
Load the selected feature's policy provenance and open-marker count through the existing boundary adapter. Cite the exact policy passage and conflicting plan action for any verified policy violation. Report unresolved decisions and which tasks depend on them. Stable task completion needs parent verification tied to the current task-contract digest; a checkbox, model claim or historical manifest alone cannot prove completion. Retain result-to-task mappings through correction, cancellation and resume.
If you haven't run the verification command in this turn, you cannot claim it passes.
Before claiming any success or expressing satisfaction:
Skip any step = the claim is unverified.
| Excuse | Reality |
|---|---|
| "I ran the tests earlier this session" | Earlier is not fresh. Code changed since. Run again. |
| "The edit was trivial, it can't break anything" | Trivial edits break builds daily. The gate has no size exemption. |
| "The subagent reported success" | Agent reports are claims, not evidence. Verify independently. |
| "CI will catch it anyway" | CI is the safety net, not the verification. Verify before push. |
| "I'm confident this works" | Confidence is not evidence. Run the command. |
| "Running the full suite is slow" | Then run the targeted suite — but run something, fresh. |
| Claim | Requires | NOT Sufficient |
|---|---|---|
| Tests pass | Test command output showing 0 failures | Previous run, "should pass" |
| Build succeeds | Build command exit 0 | Linter passing |
| Bug fixed | Reproduce original symptom: now passes | "Code changed, should work" |
| Regression test works | Red (fail without fix) → Green (pass with fix) | Test passes once |
| Subagent completed task | git diff shows expected changes | Subagent says "done" |
| Requirements met | Line-by-line checklist against spec | Tests passing |
| Provider dispatch worked | Output contains expected content | No error ≠ success |
If you catch yourself thinking any of these, STOP:
| Thought | What to do instead |
|---|---|
| "Should work now" | Run the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "The linter passed" | Linter ≠ tests ≠ build |
| "The agent said it worked" | Verify independently |
| "It's a small change" | Small changes cause big bugs |
In Claude Octopus workflows, verification is especially critical because:
After any multi-provider workflow:
# Verify synthesis file exists and is recent
ls -la ~/.claude-octopus/results/*-synthesis-*.md | tail -1
# Verify it has content (not just headers)
wc -l ~/.claude-octopus/results/*-synthesis-*.md | tail -1
ALWAYS before:
In orchestrate.sh workflows:
probe (discover) — verify synthesis file existsgrasp (define) — verify consensus score meets thresholdtangle (develop) — verify tests pass, not just that code was writtenink (deliver) — verify review actually ran, not just that it was dispatched$ npm test
✓ user.create() saves to database (45ms)
✓ user.create() validates email (12ms)
Tests: 2 passed, 2 total
All 2 tests pass. ← Claim backed by output.
I've implemented the feature. It should work now. The tests should pass.
← No test was run. "Should" is not evidence.
1. Write test → run → FAIL (expected, proves test detects the bug)
2. Implement fix → run → PASS (proves fix works)
3. Revert fix → run → FAIL (proves test isn't false-positive)
4. Restore fix → run → PASS (final confirmation)
This skill is referenced by:
flow-develop.md — verification gate after implementationflow-deliver.md — verification gate before deliveryskill-code-review.md — verify review findings before reportingskill-tdd.md — red-green cycle requires evidence at each stepskill-factory.md — autonomous pipeline must verify at every phaseまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Starter: interpret a council run's verdict artifacts — quorum, dissent, cross-lab validity, and what to do next
日本語の概要は準備中です。原文の説明を表示しています。
Starter: frame a decision as a multi-model debate — picks sides, seats providers, and launches /octo:debate with a well-formed motion
日本語の概要は準備中です。原文の説明を表示しています。
Multi-AI requirements scoping using available external providers (Double Diamond Define phase). Priority triggers: octo define, octo scope, co-define, co-scope. DO NOT use for implementation, research, review/validation, or built-in commands.
日本語の概要は準備中です。原文の説明を表示しています。
Multi-AI validation, scoring, and review using available external providers (Double Diamond Deliver phase)
日本語の概要は準備中です。原文の説明を表示しています。
Multi-AI implementation using available external providers (Double Diamond Develop phase). DO NOT use for simple code edits, reading/reviewing code, built-in commands, or trivial single-file changes.
日本語の概要は準備中です。原文の説明を表示しています。
Multi-AI research using available external providers (Double Diamond Discover phase) - Questions about best practices, patterns, or ecosystem research PRIORITY TRIGGERS (always invoke): "octo research", "octo discover", "co-research", "co-discover" DO NOT use for: simple file searches (use Read/Grep), questions Claude can answer directly, debugging issues (use skill-debug), or "what are my options" for decision support.
日本語の概要は準備中です。原文の説明を表示しています。