brainstorming

name	brainstorming
description	創作作業の前に必ず使うスキル。機能追加・コンポーネント構築・動作変更など、実装を始める前にユーザーの意図・要件・設計を整理する。「ブレインストーミングして」「アイデアを整理して」「設計を考えて」「要件を探ろう」などで発動。
metadata	{"version":"2.1.1","tier":"stable","category":"design","tags":["ideation","requirements","planning"]}

アイデアを設計に落とし込むブレインストーミング

概要

自然な対話を通じて、アイデアを完全に形になった設計・仕様へと昇華させる。

まず現在のプロジェクトの状況を把握し、質問を一問ずつ行ってアイデアを磨いていく。 何を作るかを理解したら、競合ソリューションとの比較・トレードオフマトリクスを生成し、設計を提示してユーザーの承認を得る。

設計を提示してユーザーが承認するまで、実装スキルの呼び出し・コードの記述・プロジェクトのスキャフォールディング・その他いかなる実装行動も行ってはならない。 これは「シンプルそうに見えるプロジェクト」も含め、すべてのプロジェクトに適用される。

アンチパターン：「これは単純すぎて設計不要」

すべてのプロジェクトはこのプロセスを経る。ToDoリストでも、単一関数のユーティリティでも、設定変更でも — すべて例外なく。 「シンプル」なプロジェクトこそ、検討不足の前提が最も多くの無駄な作業を生み出す。 設計は短くていい（本当に単純なプロジェクトなら数文で十分）が、必ず提示して承認を得ること。

Step 0: スコーピング（実行前確認）

以下を確認し、該当しない場合は中断して適切なスキルを提案する:

• 設計が未確定であること — 既に設計ドキュメント（docs/plans/ 内）や承認済みの設計が存在する場合は、設計の「更新」が必要か確認し、不要なら中断する
• このスキルの適用対象であること — 単純な修正・バグ修正・既存コードの変更のみの場合は、brainstorming は不要（直接実装スキルへ委譲）
• 前提情報が把握できること — リポジトリやドキュメントが存在する場合はまず既存コンテキストを読み取る

---

チェックリスト

以下の各項目をタスクとして作成し、順番に完了させること：

1. 過去の設計決定を recall — ltm-use から同テーマの過去の決定を検索し、再設計の重複を防ぐ（v2.1）
2. プロジェクトのコンテキスト探索 — ファイル・ドキュメント・最近のコミットを確認する
3. 明確化のための質問 — 一問ずつ、目的・制約・完了の定義を理解する
4. 2〜3のアプローチを提案 + トレードオフマトリクス生成 — 各アプローチを比較表で評価する
5. 既存スキルとの重複・シナジー分析 — 利用可能なスキルとの関係を明示する
6. 設計の提示 — 複雑度に応じてセクション分けして提示し、各セクション後に承認を得る
7. 設計ドキュメントを書く（Decision Record 付き） — docs/plans/YYYY-MM-DD-<トピック>-design.md に保存してコミット
8. 設計決定を ltm-use に自動保存 — Decision Record を長期記憶に保存する（v2.1）

プロセスフロー

過去の設計決定を recall（v2.1）
        ↓
プロジェクトコンテキスト探索
        ↓
 明確化の質問（一問ずつ）
        ↓
  2〜3のアプローチを提案
  ＋トレードオフマトリクス生成
  ＋既存スキルとの重複・シナジー分析
        ↓
   設計セクションを提示
        ↓
  ユーザーが設計を承認？
   ↙ No（修正）  ↘ Yes
  設計セクション再提示  設計ドキュメント作成
                    （Decision Record 付き）
                    ↓
             ltm-use へ自動保存（v2.1）
                    ↓
             実装計画を作成する

終了状態は設計ドキュメントの承認、設計決定の ltm-use 自動保存、および実装計画の作成である。 ブレインストーミング中・完了直後にコードの実装を開始してはならない。

プロセス詳細

過去の設計決定の recall（v2.1 拡張）：

• ブレインストーミング開始時に、まず同テーマの過去の決定を ltm-use から検索する：

  python scripts/recall_memory.py "[トピックキーワード] 設計決定"
  

• 関連する過去の決定が見つかった場合、採用案・却下案・理由をユーザーに提示してから議論を開始する
• 過去の決定を覆す場合は、その理由を明示して Decision Record に記録する

アイデアの理解：

• まずプロジェクトの現状を確認する（ファイル・ドキュメント・最近のコミット）
• 質問を一問ずつ行ってアイデアを深める
• 可能な限り選択肢を提示する形式を優先するが、自由回答でも構わない
• 1メッセージに質問は1つだけ — あるトピックをさらに掘り下げる必要があれば複数の質問に分割する
• 理解すべきこと: 目的・制約・完了の定義

アプローチの探索（v2 拡張）：

• トレードオフを伴う2〜3の異なるアプローチを提案する
• 各アプローチを トレードオフマトリクス（比較表）で評価する（後述）
• 推奨案とその理由を会話形式で提示する
• 推奨案を最初に提示し、理由を説明する

トレードオフマトリクス： 各アプローチを以下の軸で比較した Markdown テーブルを自動生成する：

アプローチ	実装コスト	リスク	保守性	拡張性	学習コスト	推奨度
案A	低	低	高	中	低	★★★
案B	中	中	中	高	高	★★☆
案C	高	高	低	高	中	★☆☆

評価値: 低 / 中 / 高（コスト・リスク・学習コストは低いほど良い。保守性・拡張性は高いほど良い）

• 推奨度は総合評価（★★★ / ★★☆ / ★☆☆）で示す
• プロジェクトの制約（納期・チームスキル・既存技術スタック）を考慮して評価する
• コンテキストによっては追加軸（パフォーマンス・セキュリティ・コスト等）を加えてよい

既存スキルとの重複・シナジー分析（v2 拡張）： アイデアを実装する前に、利用可能なスキルとの関係を分析する：

• 重複チェック: 「このアイデアは既存の [スキル名] でカバーできる可能性があります」と警告する
  • 例: 「テスト戦略を設計したい」→ test-strategy-planner が存在するため重複の可能性
• シナジー分析: 「[スキル名] と組み合わせると効果的です」と推薦する
  • 例: 「APIを設計する場合は api-designer を活用できます」
• 重複・シナジーがない場合は「関連スキルなし」と明示してスキップする

分析フォーマット: ───────────────────────────────── 🔍 既存スキルとの関係 ⚠️ 重複の可能性: [スキル名] — [理由] 💡 シナジー推奨: [スキル名] — [使い方の提案] ─────────────────────────────────

設計の提示：

• 何を作るか理解できたと判断したら、設計を提示する
• 各セクションを複雑度に応じてスケールする: 単純なら数文、複雑なら200〜300字程度
• 各セクションの提示後に「ここまでで問題ありませんか？」と確認する
• カバーすべき内容: アーキテクチャ・コンポーネント・データフロー・エラーハンドリング・テスト
• 何かおかしいと感じたら、遠慮なく立ち戻って明確化する

設計後の作業

ドキュメント化（v2 拡張: Decision Record 付き）：

• 確定した設計を docs/plans/YYYY-MM-DD-<トピック>-design.md に書き出す
• 設計ドキュメントの末尾に必ず Decision Record セクションを自動埋め込む：

## Decision Record

| 項目 | 内容 |
|------|------|
| 決定日 | YYYY-MM-DD |
| 決定者 | （ユーザー名 or "チーム"） |
| 採用案 | [採用したアプローチ名] |
| 却下案 | [却下したアプローチ名]（理由: ...） |
| 主な理由 | [採用の決め手となった理由] |
| トレードオフ | [受け入れたデメリットや制約] |
| 再評価条件 | [この決定を見直すべき状況・タイミング] |

• 簡潔で明確な文章を心がける
• 設計ドキュメントを git にコミットする

設計決定の ltm-use 自動保存（v2.1 拡張）：

設計ドキュメントのコミット直後に、Decision Record を長期記憶として自動保存する：

python scripts/save_memory.py --non-interactive --no-dedup \
  --scope home \
  --category design \
  --title "[トピック名] の設計決定" \
  --summary "[採用案] を採用。[主な理由の1文要約]。" \
  --content "設計ドキュメント: docs/plans/YYYY-MM-DD-[トピック]-design.md" \
  --tags design,decision,[トピック関連タグ]

• --scope home: 設計決定はプロジェクト横断で価値があるため home スコープに保存する
• --content にはファイルパスを記録する（全文は git 管理のドキュメントに存在するため重複不要）
• 保存後は「〇〇の設計決定を記憶しました（mem-XXXXXX-NNN）」と簡潔に報告する
• 同じトピックで再設計が必要になった際に、過去の決定を自動的に参照できるようになる

実装：

• 詳細な実装計画を作成する

主要原則

• 質問は一問ずつ — 複数の質問で圧倒しない
• 選択肢を優先 — 可能な限り選択肢形式の方が答えやすい
• YAGNI の徹底 — すべての設計から不必要な機能を排除する
• 代替案の探索 — 方針を決める前に常に2〜3のアプローチを提案する
• トレードオフを可視化 — 比較表でアプローチの差異を明確にし、意思決定を加速する（v2）
• スキルの重複を避ける — 既存スキルで代替できる場合は率直に伝える（v2）
• 決定を記録する — Decision Record により未来の自分・チームへの文脈を残す（v2）
• 決定を記憶する — ltm-use への自動保存により、同テーマの再設計時に過去の意思決定を即座に参照できる（v2.1）
• 段階的な検証 — 設計を提示し、次に進む前に承認を得る
• 柔軟に対応 — 何かおかしいと感じたら戻って明確化する