القائمة
完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。
التثبيت باستخدام 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 になる。テスト件数や出力内容まで確認する