/clarify Skill - 暗黙知抽出ワークフロー
仕様駆動開発（SDD）の最上流工程を担当するSkill。
ユーザーの頭の中にある暗黙知を対話的に引き出し、/spec に引き継ぎ可能な形式で言語化します。
発動条件
以下のキーワードで自動発動：
- •「要件を整理して」「暗黙知を言語化して」
- •「仕様策定の前に」「specの前に」
- •「clarifyして」「明確化して」
- •「何を決めるべき？」「何を考慮すべき？」
基本原則
- •段階的対話: ラウンド形式で深掘り（最大4ラウンド）
- •質問上限: 1ラウンドあたり最大3問
- •収束判断: ユーザーの「十分」「次に進んで」で終了
- •成果物: トレードオフ表と決定事項サマリーを出力
ワークフロー
全体フロー
code
┌─────────────────────────────────────────────────────┐ │ /clarify 開始 │ │ │ │ │ ├─ Round 1: 定義と基本戦略 │ │ │ └─ 最大3問 → 回答待ち │ │ │ │ │ ├─ Round 2: トレードオフの掘り下げ │ │ │ └─ 最大3問 → 回答待ち │ │ │ │ │ ├─ Round 3: 技術的制約 │ │ │ └─ 最大3問 → 回答待ち │ │ │ │ │ ├─ Round 4: 最終確認 │ │ │ └─ 最大3問 → 回答待ち │ │ │ │ │ └─ 出力生成 │ │ ├─ トレードオフ表 │ │ ├─ 決定事項サマリー │ │ └─ /spec への引き継ぎ │ └─────────────────────────────────────────────────────┘
Round 1: 定義と基本戦略
目的: 曖昧な言葉を具体化し、基本方針を確認
code
┌─────────────────────────────────────────────────────┐ │ 質問カテゴリ: │ │ 1. 定義の明確化 │ │ - 「〇〇」とは具体的に何を指す？ │ │ - 「成功」の定義は？ │ │ │ │ 2. シグナルの優先順位 │ │ - 暗黙的な入力をどう解釈する？ │ │ - 明示的 vs 暗黙的の優先度は？ │ │ │ │ 3. コールドスタート │ │ - データがない状態でどう対応？ │ │ - 初期フェーズの戦略は？ │ │ │ │ ユーザー回答後 → Round 2へ（または「十分」で終了） │ └─────────────────────────────────────────────────────┘
Round 2: トレードオフの掘り下げ
目的: 二項対立する選択肢の判断基準を明確化
code
┌─────────────────────────────────────────────────────┐ │ 質問カテゴリ: │ │ 1. 時間的変化 │ │ - 過去のデータはどう減衰させる？ │ │ - 「復活」のタイミングは？ │ │ │ │ 2. UIトレードオフ │ │ - 誰が選ぶか？（システム vs ユーザー） │ │ - ユーザー負担と情報取得のバランスは？ │ │ │ │ 3. 属性の考慮 │ │ - 副次的属性をどう扱う？ │ │ - 重み付けの基準は？ │ │ │ │ ユーザー回答後 → Round 3へ（または「十分」で終了） │ └─────────────────────────────────────────────────────┘
Round 3: 技術的制約
目的: 実装上の制約を確認し、現実的な解を導く
code
┌─────────────────────────────────────────────────────┐ │ 質問カテゴリ: │ │ 1. UIの粒度 │ │ - どこまで細かく設定させる？ │ │ - 複雑性 vs 精度のバランスは？ │ │ │ │ 2. 計算リソース │ │ - リアルタイム vs バッチの判断基準は？ │ │ - コスト許容範囲は？ │ │ │ │ 3. 段階的アプローチ │ │ - MVPで割り切ってよい機能は？ │ │ - 後回しにできる要素は？ │ │ │ │ ユーザー回答後 → Round 4へ（または「十分」で終了） │ └─────────────────────────────────────────────────────┘
Round 4: 最終確認
目的: 残った不明点を解消し、決定事項を確定
code
┌─────────────────────────────────────────────────────┐ │ 質問カテゴリ: │ │ 1. 動的調整 │ │ - パラメータは固定？動的？ │ │ - 調整の頻度・トリガーは？ │ │ │ │ 2. 新規アイテム対応 │ │ - 新着の扱いは？ │ │ - 既存との統合方法は？ │ │ │ │ 3. MVP範囲の最終確認 │ │ - 後回しにしてよいものの再確認 │ │ - 必須 vs Nice-to-have の線引き │ │ │ │ ユーザー回答後 → 出力生成 │ └─────────────────────────────────────────────────────┘
質問生成ルール
質問の優先順位
- •ブロッカー質問: 回答なしでは仕様が書けない
- •方向性質問: 複数のアプローチがあり選択が必要
- •詳細質問: 細部の仕様を確定する
質問のフォーマット
markdown
## Round X: [フェーズ名] ### 質問 1: [質問タイトル] [質問本文] **選択肢（参考）:** - A: [選択肢Aの説明] - B: [選択肢Bの説明] - その他: 自由回答も可 ### 質問 2: [質問タイトル] ...
回答の集約
ユーザー回答を受け取ったら：
- •回答を解釈し、決定事項として記録
- •新たな質問が派生したか確認
- •次のラウンドへ進むか、終了するか判断
出力形式
トレードオフ表
markdown
## トレードオフ分析 | 観点 | 選択肢A | 選択肢B | 決定 | 理由 | | ------- | ------- | ------- | ---- | ------ | | [観点1] | [説明] | [説明] | A/B | [理由] | | [観点2] | [説明] | [説明] | A/B | [理由] |
決定事項サマリー
markdown
## 決定事項サマリー ### 定義 - **[用語1]**: [定義] - **[用語2]**: [定義] ### 基本方針 1. [方針1] 2. [方針2] ### 技術的制約 - [制約1] - [制約2] ### MVPスコープ **含む:** - [機能1] - [機能2] **含まない（将来対応）:** - [機能3] - [機能4] ### 未決定事項（/spec で詳細化） - [未決定1] - [未決定2]
/spec 引き継ぎ形式
markdown
## /spec 引き継ぎ情報 ### ユーザーストーリー素案 > [ペルソナ] として、[目的] して、[価値] したい。 ### AC候補 - [ ] [AC1] - [ ] [AC2] ### 設計制約 - [制約1] - [制約2] ### 参照 - 元の要件: [ユーザーの最初の入力] - clarifyセッション: [日付]
対話制御コマンド
| コマンド | 動作 |
|---|---|
| 「十分」「これで十分」 | 現ラウンドで終了し、出力生成へ |
| 「次に進んで」 | 次のラウンドへ進む |
| 「もう少し深掘りして」 | 同じカテゴリで追加質問 |
| 「[話題]について詳しく」 | 特定トピックを深掘り |
| 「スキップ」 | 現ラウンドをスキップ |
| 「/spec に進んで」 | 即座に /spec Skill へ移行 |
使用例
例1: 推薦ロジックの暗黙知抽出
code
ユーザー: 「推薦機能を作りたいんだけど、要件を整理して」 [自動] /clarify Skill発動 Claude: /clarify を開始します。推薦機能の暗黙知を引き出していきます。 ## Round 1: 定義と基本戦略 ### 質問 1: 「好み」のシグナル優先順位 ユーザーの「好み」を判断する際、以下のシグナルをどう優先しますか？ - 明示的: Like/Dislikeボタン、お気に入り登録 - 暗黙的: 閲覧時間、スクロール深度、再訪問 ### 質問 2: コールドスタート戦略 新規ユーザー（データなし）への初期推薦はどうしますか？ - A: 人気順で表示 - B: ランダム表示 - C: オンボーディングで好みを聞く ### 質問 3: 成功指標 「適切な推薦」とは何で測定しますか？ ユーザー: 「明示的を優先、コールドスタートはCで、成功はクリック率で」 Claude: 了解しました。決定事項として記録します。 **Round 1 決定事項:** - シグナル優先: 明示的 > 暗黙的 - コールドスタート: オンボーディング方式 - 成功指標: クリック率（CTR） ## Round 2: トレードオフの掘り下げ... （以下続く）
例2: 早期終了パターン
code
ユーザー: 「APIの設計を整理して」 Claude: /clarify を開始します。 ## Round 1: 定義と基本戦略 ### 質問 1: API利用者 このAPIの主な利用者は？ ... ユーザー: 「十分です。この内容で /spec に進んで」 Claude: 了解しました。現時点の決定事項をまとめて /spec に引き継ぎます。 （出力生成 → /spec 発動）
禁止事項
- •1ラウンドで4問以上の質問をしない
- •ユーザーの回答を待たずに次のラウンドへ進まない
- •曖昧な回答を勝手に解釈して決定事項にしない
- •技術的な解決策を先走って提案しない（それは /spec の役割）
連携フロー
code
/clarify（暗黙知抽出）← 本Skill
│
└─ 出力: トレードオフ表 + 決定事項サマリー
↓
/spec（仕様策定）
├─ /clarify の出力を入力として使用
├─ Phase 1: Requirements Discovery
├─ Phase 2: Design Exploration
└─ Phase 3: Task Breakdown
/spec への自動引き継ぎ
/clarify 完了時、ユーザーが希望すれば /spec を自動発動：
code
Claude: /clarify の成果物を生成しました。 ## トレードオフ分析 （表） ## 決定事項サマリー （サマリー） /spec に進みますか？ - 「/spec に進んで」→ /spec Skill発動 - 「一旦保存」→ 成果物のみ保存
関連Skill
- •/spec: 仕様策定（本Skillの下流工程）
- •spec-workflow: 実装（/spec の下流工程）
全体連携フロー
code
/clarify（暗黙知抽出）← 本Skill
│
└─ 決定事項サマリー
↓
/spec（仕様策定）
├─ /branch 発火（spec/*）
├─ ファイル生成
└─ /pr 発火（仕様レビュー）
↓ マージ後
spec-workflow（実装）
├─ /branch 発火（impl/*）
├─ TDD実装
└─ /pr 発火（実装レビュー）