backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
kok1eee/o-m-cc62026年6月9日 更新
無料GitHub で公開
verification
完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。
実装完了時、バグ修正後、テスト通過を宣言する前に使う。
含まれるファイル（1）
- SKILL.md6.3 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Verification Before Completion
証拠なき成功宣言は不正。書いた人の「動くはず」は信用しない。
完了を宣言する前に、必ずこのチェックリストを通すこと。
姿勢: Adversarial（敵対的検証）
- 実装者の味方ではない。壊せるか試す立場
- 「動くはず」「テスト通るはず」を信用しない
- ハッピーパスだけでなく、エッジケース・異常系・境界値を積極的に試す
- 部分的な成功を完全な成功と混同しない
Iron Law
検証コマンドを実行し、その出力を確認するまで、成功・完了・修正済みを宣言してはならない。
「さっき通ったから大丈夫」は証拠にならない。今この瞬間の実行結果だけが証拠。
検証プロセス
Step 1: IDENTIFY — 何が成功を証明するか
宣言しようとしている内容に応じて、必要な証拠を特定する：
| 宣言 | 必要な証拠 |
|---|---|
| 「テストが通る」 | テストコマンドの実行結果（exit code 0 + 出力） |
| 「バグを修正した」 | 元の症状が再現しないことを示すテスト結果 |
| 「機能を実装した」（runnable） | 実際に起動し、要件のユーザーパスを実行した証拠（出力 / スクショ / レスポンス）。下記「挙動検証」参照 |
| 「リファクタリング完了」 | 既存テストが全て通ること |
| 「ビルドが通る」 | ビルドコマンドの成功出力 |
Step 2: RUN — 検証コマンドを実行
実行すべきコマンドを特定し、Bash で実行する。
前回の実行結果は使わない。必ず今実行する。
Step 3: READ — 出力を完全に確認
- exit code を確認
- 出力を最後まで読む（途中で切らない）
- 警告やスキップされたテストも確認
Step 4: VERIFY — 出力が宣言を裏付けるか判定
- 期待する結果と実際の結果を照合
- 部分的な成功を完全な成功と混同しない
- 「0 tests ran」は「全テスト通過」ではない
Step 5: DECLARE — 証拠付きで宣言
証拠が揃って初めて完了を宣言する。宣言には：
- 何を実行したか
- 結果はどうだったか を含める。
挙動検証 — runnable な変更は「動かして観測」まで
テストが緑でも挙動が正しいとは限らない。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 も実行面も無い変更は、この節をスキップしてコマンド証拠で足りる。
よくある落とし穴
| やりがち | 正しい対応 |
|---|---|
| 「テスト通りました」（実行せず） | テストコマンドを実行して出力を確認 |
| 前回の結果を引用 | 今実行した結果のみが証拠 |
| 一部のテストだけ実行 | 影響範囲の全テストを実行 |
| ビルドエラーを無視して「完了」 | ビルド成功まで完了と言わない |
| 「動くはず」という推論 | 実際に動かして確認 |
/quality-gate との関係
- verification: 個別の完了宣言に対する証拠確認（ミクロ）
- quality-gate: コードベース全体の品質レビュー（マクロ）
両方使うのが理想。verification で個々のタスクの完了を確認し、quality-gate で全体の品質を保証する。
Memory 蓄積
検証で繰り返し発見したパターンは auto-memory に保存すること：
- 繰り返し失敗するテストパターン（例: 環境依存で落ちる、タイムアウトしやすい）
- プロジェクト固有のテストコマンドと注意点（例:
npm testの前にnpm run buildが必要） - よくある見落とし（例: このプロジェクトでは型チェックが通ってもランタイムで落ちるパターンがある）
蓄積しない:
- 個別のテスト結果（確証バイアスの原因になる）
- セッション固有の一時的な失敗
Gotchas
- テストコマンドが不明で実行しない: CLAUDE.md にテストコマンドが書かれていない場合、
package.jsonの scripts やMakefileを確認する。それでも不明なら AskUserQuestion で聞く - exit code 0 だけ見て出力を読まない:
0 tests ranでも exit 0 になる。テスト件数や出力内容まで確認する - ビルドの警告を無視: 警告はエラーではないが、新規の警告は報告すべき
- テスト緑 = 挙動正しい、と誤認: 静的チェック（test / build / 型）の通過は必要条件であって十分条件ではない。runnable な変更は起動して観測するまで「動く」と言わない。長時間自律ループではこの挙動ゲートがドリフト防止の本体
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
kok1eee/o-m-cc62026年6月9日 更新
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。
kok1eee/o-m-cc62026年6月9日 更新
3エージェント（researcher, analyst, scout）による並列要件分析 Council。peer-to-peer で相互検証し requirements.md を確定。「要件を整理して」「要件定義して」「現状分析して」「要件をまとめて」で発動。
kok1eee/o-m-cc62026年6月9日 更新
技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。
kok1eee/o-m-cc62026年6月9日 更新
スキルの自己進化。auto-memory と実行履歴から学びを抽出し、各スキルの Gotchas セクションに自動追記する。セッション終了前、定期的な改善サイクル、問題に遭遇した後に使う。「スキルを進化させて」「学びを反映して」「Gotchas を更新」「evolve」で発動。
kok1eee/o-m-cc62026年6月9日 更新