skill-verify

ホスト：Codex CLI — このスキルはClaude Code向けに設計され、Codex向けに調整されています。 相互参照コマンドでは、/octo:* スラッシュコマンドではなく、Codexにインストールされたスキル名を使用します。 現在のCodexシェルとサブエージェントツールを使用してください。現在のセッションで利用可能であることが確認されるまでは、プロバイダー、モデル、ホストのサブエージェントが利用可能だと断言しないでください。 ホストツールに相当するものについては、skills/blocks/codex-host-adapter.mdを参照してください。

検証ゲート

移植可能な機能の証拠

既存の境界アダプターを通じて、選択した機能のポリシーの出所と未完了マーカー数を読み込みます。検証済みのポリシー違反については、該当するポリシーの正確な記述と、矛盾する計画上のアクションを示してください。未解決の判断事項と、それに依存するタスクを報告します。タスクの完了が確定するには、現在のタスク契約ダイジェストに紐づく親による検証が必要です。チェックボックス、モデルの申告、過去のマニフェストだけでは、完了の証明にはなりません。修正、キャンセル、再開の際も、結果とタスクの対応関係を保持してください。

鉄則

最新の検証証拠なしに、完了を主張してはなりません

このターンで検証コマンドを実行していないなら、合格したと主張することはできません。

ゲート

成功を主張したり、満足を表明したりする前に、次の手順を実行してください。

1. 特定 — この主張を証明するコマンドは何ですか？
2. 実行 — コマンドを最後まで実行します（キャッシュではなく、最新の状態で）。
3. 確認 — 出力全体を読み、終了コードを確認し、失敗数を数えます。
4. 検証 — 出力は実際にその主張を裏付けていますか？
5. その後にのみ — 証拠を添えて主張します。

手順を1つでも省略すれば、その主張は未検証です。

正当化の一覧

言い訳	実際のところ
「このセッションの前のほうでテストを実行した」	以前の実行は最新ではありません。その後コードが変更されています。もう一度実行してください。
「些細な編集だから、何も壊れない」	些細な編集がビルドを日々壊しています。このゲートに変更規模の例外はありません。
「サブエージェントが成功を報告した」	エージェントの報告は主張であり、証拠ではありません。自分で検証してください。
「どうせCIが検出する」	CIはセーフティネットであり、検証そのものではありません。プッシュ前に検証してください。
「これで動くと確信している」	確信は証拠ではありません。コマンドを実行してください。
「全テストスイートの実行には時間がかかる」	それなら対象を絞ったテストスイートを実行してください。それでも何かを最新の状態で実行する必要があります。

証拠として認められるもの

主張	必要なもの	不十分なもの
テストに合格	失敗数が0と示されたテストコマンドの出力	過去の実行結果、「合格するはず」という見込み
ビルドに成功	ビルドコマンドの終了コードが0	リンターの合格
バグを修正	元の症状を再現し、現在は合格すること	「コードを変更したので動くはず」
リグレッションテストが機能	赤（修正なしでは失敗）→緑（修正ありでは合格）	1回だけテストに合格
サブエージェントがタスクを完了	git diffに期待される変更が表示されること	サブエージェントの「完了しました」という報告
要件を満たしている	仕様に照らした行ごとのチェックリスト	テストの合格
プロバイダーへのディスパッチが機能	出力に期待される内容が含まれること	エラーがないこと ≠ 成功

危険信号 — 停止して検証する

次のように考えていることに気づいたら、停止してください。

考え	代わりにすること
「これで動くはず」	検証を実行する
「確信している」	確信 ≠ 証拠
「今回だけ」	例外なし
「リンターに合格した」	リンター ≠ テスト ≠ ビルド
「エージェントが動いたと言っていた」	自分で検証する
「小さな変更だ」	小さな変更が大きなバグを引き起こす

マルチプロバイダーのコンテキスト

Claude Octopusのワークフローでは、次の理由から検証が特に重要です。

• プロバイダーの出力は幻覚の可能性があります — Codex、Antigravity、Copilotなどのプロバイダーは、証拠なしに成功したと主張することがあります
• 合意 ≠ 正しさ — 3つのモデルが同意していても、正しいとは限りません
• 統合ファイルが古い可能性があります — タイムスタンプを確認し、最新だと思い込まないでください
• orchestrate.shの終了コード0 ≠ 品質 — スクリプトは実行されましたが、良質な出力を生成しましたか？

マルチプロバイダーのワークフローの後は、次を実行してください。

# 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

適用するタイミング

必ず次の前に実施してください：

• コードをコミットする
• PR を作成する
• タスクを完了としてマークする
• 次のワークフローフェーズに進む
• ユーザーに結果を報告する
• バグが修正されたと主張する

orchestrate.sh のワークフローでは：

• probe（発見）の後 — 統合ファイルが存在することを確認する
• grasp（定義）の後 — 合意スコアがしきい値を満たしていることを確認する
• tangle（開発）の後 — コードが書かれたことだけでなく、テストが通ることを確認する
• ink（納品）の後 — レビューが割り当てられただけでなく、実際に実行されたことを確認する

例

正しい例：エビデンスに基づく主張

$ 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)

他のスキルとの連携

このスキルは次から参照されています：

• flow-develop.md — 実装後の検証ゲート
• flow-deliver.md — 納品前の検証ゲート
• skill-code-review.md — 報告前にレビュー結果を検証する
• skill-tdd.md — レッド・グリーンサイクルでは各ステップでエビデンスが必要
• skill-factory.md — 自律型パイプラインでは各フェーズで検証が必要