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 で公開
deep-interview
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。
※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
含まれるファイル（1）
- SKILL.md4.2 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Deep Interview - ソクラテス式要件掘り下げ
discovery-council の前段。要件が曖昧なときに使う。まだ plan が無い段階で要件を引き出すのが役割。逆に既にある plan/design を詰問したいなら /o-m-cc:grill（こちらは掘り下げでなく stress-test）。
対話前提スキル: 1 問ずつの掘り下げが本質なので、AskUserQuestion が使えない環境では「要件が曖昧です。対話モードで /deep-interview を実行してください」と案内して終了する。
入力
$ARGUMENTS（ユーザーの曖昧なアイデア・要望）
原則
- 1回に1つの質問。バッチで聞かない
- 前の回答を踏まえて次の質問を決める
- 選択肢を提示する（答えやすくする）
- 「なぜ？」「たとえば？」「もし○○なら？」の形で掘り下げる
- 最大 7問 で打ち切る（ユーザーの負担を最小化）
5軸の曖昧性評価
各質問の前に、以下の5軸で内部評価する（ユーザーには見せない）:
| 軸 | 問い |
|---|---|
| WHO | 誰のための機能か？ユーザーは誰か？ |
| WHAT | 何を実現するか？具体的な振る舞いは？ |
| WHY | なぜ必要か？現状の課題は何か？ |
| SCOPE | 何を含み、何を含まないか？ |
| CONSTRAINT | 技術的制約、期限、依存は？ |
Step 1: 初期分析
ユーザー入力を読み、5軸それぞれを [明確 / やや曖昧 / 曖昧] で評価する。既存コードベースがある場合は Glob/Grep/Read で関連コードを確認し、質問の精度を上げる。
Step 2: インタビューループ
最も曖昧な軸から順に1問ずつ質問する。
AskUserQuestion:
question: "<最も曖昧な軸に対する具体的な質問>"
options:
- "<選択肢A>"
- "<選択肢B>"
- "<選択肢C>"
- "自由に記述"
質問の形: 「なぜ？」「たとえば？」「もし○○なら？」で掘り下げ、必ず3-4個の選択肢 + 自由記述を提示する。
ループ終了条件: 全軸が [明確] / 7問到達 / ユーザーが「もういい」「十分」。
回答への対応:
- 「分からない」→ 仮定を提案して確認を取る（「○○と仮定してよいですか？」）
- 抽象的な回答 → 具体例を求める（「たとえばどんなケースですか？」）
- 矛盾する回答 → 優先順位を聞く（「○○と△△は両立しにくいですが、どちらを優先しますか？」）
Step 3: 要件サマリーの確認
掘り下げた結果を5軸で構造化し、最終確認する（OK / 修正あり）。
Step 4: discovery-council へハンドオフ
確認が取れたら、整理した要件をそのまま discovery-council に渡す:
Skill: discovery-council
Args: <整理された要件サマリー>
Gotchas
- 7問超過でユーザー疲弊: 7問で打ち切り、残った曖昧軸は仮定として明記して discovery-council へ渡す（完璧を狙って質問しすぎない）
- 既にある plan を掘り下げ直さない: 完成した plan/design を持っているなら、掘り下げでなく
/o-m-cc:grill（詰問）を使う。deep-interview は「ゼロから要件を引き出す」用途 - 初期分析を飛ばすと無駄質問: Step 1 で5軸評価＋既存コード確認をせずに質問を始めると、コードを見れば分かることを聞いてループが伸びる
- 「分からない」を放置しない: 仮定を提案して確認を取る。抽象回答は具体例を、矛盾回答は優先順位を聞く
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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日 更新
実験駆動の反復改善ループ（autoresearch 方式）。毎回フレッシュなサブエージェントで 1変更→測定→保持 or revert。progress.md がイテレーション間の記憶。パフォーマンス最適化、リファクタリング、UI改善、バグ修正の試行錯誤に使う。「最適化して」「パフォーマンス改善」「リファクタリング」「試行錯誤して」「実験的に改善」で発動。
kok1eee/o-m-cc62026年6月9日 更新