メニュー
完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
新機能を実装まで一気通貫で走らせる action skill。Agent Teams で要件・設計・タスク分解・実装・quality-gate を自動実行し、コードがコミット可能な状態になるまで止まらない（Sisyphus Loop）。auto mode でも planning ではなく action として積極発動する。「実装して」「作って」「機能を追加して」「新機能を作りたい」「要件から実装まで一気に」「計画して」「この機能を実装したい」で発動。
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
完成した plan/design を対話で容赦なく詰問し、実装前に穴を潰す。決定木を1枝ずつ降り、各質問に推奨回答を添える。コードで答えが出る点は聞かず自分で調べて埋める。「grill して」「叩いて」「この設計で大丈夫?」「plan を詰めて」「設計を対話レビュー」で発動。※ ゼロから要件を掘り下げるなら deep-interview、非対話で一括批判レポートなら critic。
backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。
技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。
| name | verification |
| description | 完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。 |
| allowed-tools | ["Read","Bash","Glob","Grep","Agent","Skill"] |
| effort | medium |
証拠なき成功宣言は不正。書いた人の「動くはず」は信用しない。
完了を宣言する前に、必ずこのチェックリストを通すこと。
検証コマンドを実行し、その出力を確認するまで、成功・完了・修正済みを宣言してはならない。
「さっき通ったから大丈夫」は証拠にならない。今この瞬間の実行結果だけが証拠。
宣言しようとしている内容に応じて、必要な証拠を特定する：
| 宣言 | 必要な証拠 |
|---|---|
| 「テストが通る」 | テストコマンドの実行結果（exit code 0 + 出力） |
| 「バグを修正した」 | 元の症状が再現しないことを示すテスト結果 |
| 「機能を実装した」（runnable） | 実際に起動し、要件のユーザーパスを実行した証拠（出力 / スクショ / レスポンス）。下記「挙動検証」参照 |
| 「リファクタリング完了」 | 既存テストが全て通ること |
| 「ビルドが通る」 | ビルドコマンドの成功出力 |
実行すべきコマンドを特定し、Bash で実行する。
前回の実行結果は使わない。必ず今実行する。
証拠が揃って初めて完了を宣言する。宣言には：
テストが緑でも挙動が正しいとは限らない。runnable な変更（web アプリ / サーバ / CLI / UI を持つもの）は、検証コマンドの緑だけで完了宣言しない。 実際に起動し、要件のユーザーパスを実行して観測する。長時間の自律ループでは、この挙動ゲートが無いと静的シグナルだけでドリフトする。
動かし方は native skill に委譲する（再実装しない）:
| 対象 | 委譲先 |
|---|---|
| アプリを起動して変更が効いているか観測 | built-in Skill: run / Skill: verify |
| ブラウザ操作を伴うフロー（クリック / 入力 / 遷移） | Skill: webapp-testing / webwright（Playwright 操作 + スクショ証拠） |
| サーバ / API | 起動して該当エンドポイントを叩き、レスポンスを Step 4 で照合 |
得られた証拠（出力 / スクリーンショット / レスポンス）を Step 4（VERIFY）で要件と照合する。起動・観測できない場合は「未検証」扱いとし、成功宣言しない（Iron Law の挙動版）。docs-only / 純粋ロジックのみで UI も実行面も無い変更は、この節をスキップしてコマンド証拠で足りる。
| やりがち | 正しい対応 |
|---|---|
| 「テスト通りました」（実行せず） | テストコマンドを実行して出力を確認 |
| 前回の結果を引用 | 今実行した結果のみが証拠 |
| 一部のテストだけ実行 | 影響範囲の全テストを実行 |
| ビルドエラーを無視して「完了」 | ビルド成功まで完了と言わない |
| 「動くはず」という推論 | 実際に動かして確認 |
両方使うのが理想。verification で個々のタスクの完了を確認し、quality-gate で全体の品質を保証する。
検証で繰り返し発見したパターンは auto-memory に保存すること：
npm test の前に npm run build が必要）蓄積しない:
package.json の scripts や Makefile を確認する。それでも不明なら AskUserQuestion で聞く0 tests ran でも exit 0 になる。テスト件数や出力内容まで確認する