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