brainstorming について
brainstormingは、複雑な機能や動作変更を計画するための設計優先スキルです。プロジェクトの調査、質問による要件確認、案の比較を進め、実装計画の前に設計承認を求めます。
主な機能
- 01プロジェクトの背景と調査結果の把握
- 02質問を一度に一つずつ確認
- 03設計案の作成と比較
- 04コーディング前の設計承認
- 05承認済み設計を docs/plans/ に保存
- 06調査結果を APEX Analyze に引き継ぎ
活用シーン
- 01実装前の新機能の計画
- 02大規模変更の選択肢の比較
- 03APEX Analyze向けの承認済み設計の準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/brainstormingを入力して読み込まれたか確認します。
同梱ファイルreferences/anti-patterns.mdreferences/workflow.md
詳細
自明な修正、タイプミス、単純なリネームについては完全にスキップします -- それらは直接 APEX へ進みます。
ブレインストーミングスキル
設計を最優先するアプローチ：設計承認前にコードを書かない。
エージェントワークフロー（必須）
ブレインストーミングセッションの前に、必ずエージェントを並列で起動します。それぞれ name を伴う Agent 呼び出しを1回ずつ行います。
- fuse-ai-pilot:explore-codebase - プロジェクトのコンテキスト、パターン、制約を理解する
- fuse-ai-pilot:research-expert - ベストプラクティスとドキュメントを取得する
設計承認後、APEX Analyze フェーズへ移行し、引き継ぎ時に（設計ドキュメントだけでなく）explore-codebase と research-expert の調査結果も渡します。APEX Analyze はデフォルトでそれら同じエージェントを再実行します — ここですでに収集したものを引き継ぐことで、同じ調査を二度行うのを避けられます。
概要
| シナリオ | アクション |
|---|---|
| 新機能 | フルブレインストーミング（6ステップ） |
| 大きな変更 | フルブレインストーミング（6ステップ） |
| コンポーネント作成 | フルブレインストーミング（6ステップ） |
| 自明な修正（1〜3行） | ブレインストーミングをスキップし、APEX へ進む |
| 単純なリネーム／タイプミス | ブレインストーミングをスキップし、APEX へ進む |
6ステッププロセス
ステップ1：プロジェクトコンテキストの調査
質問をする前にコンテキストを収集します：
git log --oneline -20- 最近の変更と方向性- 既存のコードパターンと規約
- 関連するドキュメントと過去の決定事項
- 技術スタックと依存関係の制約
ステップ2：明確化のための質問（一度に1つずつ）
焦点を絞った質問を順番に行います。次に進む前に各回答を待ちます。
カテゴリ：目的、制約、成功基準、ユーザー、連携。
質問のカテゴリについては workflow.md を参照してください
ステップ3：発散させてから2〜3個のアプローチに収束させる
名前の付いた手法（SCAMPER／逆ブレインストーミング／類推）を用いて、6〜8個以上の異なるアプローチを生成します。判断は保留します — 同じアイデアの3つのバリエーションではありません。その後になって初めて、トレードオフを表形式で示しながら2〜3個に収束させます：
| アプローチ | 長所 | 短所 | 推奨 |
|---|---|---|---|
| 選択肢A | ... | ... | ... |
| 選択肢B | ... | ... | ... |
| 選択肢C | ... | ... | ... |
根拠を伴う明確な推奨を必ず含めます。
ステップ4：承認のために設計を提示する
設計を理解しやすいセクションに分割します：
- アーキテクチャの概要
- 主要なコンポーネントと責務
- データフローと状態管理
- エッジケースとエラー処理
先に進む前に、ユーザーからの明示的な承認を待ちます。
ステップ5：設計ドキュメントの保存
承認された設計を docs/plans/YYYY-MM-DD-<topic>-design.md に保存します。
ステップ6：APEX への移行
承認された設計を入力として、APEX Analyze フェーズへ引き継ぎます。
リファレンスガイド
| トピック | リファレンス | 参照するタイミング |
|---|---|---|
| ワークフロー | workflow.md | 質問のカテゴリ、提案の形式、設計テンプレート |
| アンチパターン | anti-patterns.md | ブレインストーミングをスキップしようとする正当化を見つける |
クイックリファレンス
1. Explore → git log, codebase, docs (agents in parallel)
2. Question → ONE AT A TIME, wait for answers
3. Diverge → 6-8 options (named technique), converge to 2-3 with trade-offs table
4. Design → Present sections, get approval
5. Save → docs/plans/YYYY-MM-DD-<topic>-design.md
6. Handoff → APEX Analyze with approved design + prior research (no re-research)
重要なルール
- 設計承認前に決してコードを書かない - 常に設計を最優先
- 質問は一度に1つずつ行う - 10個の質問のリストを一度に投げかけない
- 常に代替案を提示する - 最低2つのアプローチをトレードオフ付きで
- 設計ドキュメントを保存する - 監査証跡と共有リファレンスを作成する
- 明示的な承認を得る - 先に進む前に「良さそうです」または同様の確認を