brainstorming について
brainstormingは、仕様やコードを書く前に対話を通じて課題、対象ユーザー、範囲を明確にする発見スキルです。一度に一つ質問し、先にプロジェクトの状況を調べ、方向性を決める前に案を比較します。
主な機能
- 01一度に一つ質問
- 02選択式の質問を優先
- 03先にプロジェクト状況を確認
- 04課題、ユーザー、範囲を検討
- 05案を比較し方向性を確認
活用シーン
- 01初期アイデアを明確な課題に整理
- 02機能仕様の作成前に範囲を整理
- 03リファクタリングや修正の進め方を決定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/brainstormingを入力して読み込まれたか確認します。
詳細
ブレインストーミング
実装仕様を書いたり、コードに触れたりする前に、協働的な対話を通じて、曖昧な意図を共通理解へとつなげます。このスキルは、探索段階の基盤となる質問の進め方です。write-idea と write-prd は、どちらもこのような会話が行われていることを前提としています。
アンチパターン：「簡単すぎて探索は必要ない」
ToDo リスト、単機能のユーティリティ、設定の変更――どれもこのプロセスを通します。検討していない前提によって、最も多くの作業が無駄になるのは「簡単な」依頼です。本当に簡単な作業なら、探索は3つの質問と2分で済むこともありますが、必ず実施してください。
質問の進め方
- 1回のメッセージにつき質問は1つ。 深掘りが必要なテーマは、質問票にせず、質問を順番に重ねてください。
- 選択肢が決められる場合は、選択式を優先します。 選択肢は2〜3個にし、推奨するものを先頭に置いて
(Recommended)と明記します。Otherは選択肢に含めません。選択肢を事前に決められない場合は、自由回答形式で構いません。構造化質問ツールではカスタム回答欄が自動で提供されます。そのようなツールがない場合は、チャットで同じ質問を1つだけ提示し、自由回答を受け付けてください。 - 質問する前に探索します。 まず、ファイル、ドキュメント、
CONTEXT.md、docs/specs/にある有効な Specs、docs/history/specs/にある廃止済み Specs、最近のコミットなど、プロジェクトの状態を確認してください。コードベースから答えがわかる質問で、ユーザーの時間を無駄にしないでください。 - HOW ではなく、WHAT、WHY、WHO。 データベース、API、フレームワーク、アーキテクチャについては技術仕様の段階で扱います。ここで取り上げると、プロダクトについての会話が脱線します。
- YAGNI を徹底します。 価値を実現できる最小のバージョンと照らし、あらゆる機能の必要性を検討してください。
質問フェーズ
会話またはコードベースですでに回答されている項目は飛ばし、次の順に進めます。最低3問、最大約6問とし、課題、ユーザー、スコープが明確になったら早めに終えます。
- 課題／困りごと — 具体的にどのような課題を解決しますか？ 何がきっかけですか？ 曖昧な場合は、考えられる解釈を2〜3個提示してください。
- 対象ユーザーと利用状況 — 誰のためのものですか？ ワークフローのどこで使いますか？ 現在はどのような回避策を使っていますか？
- スコープ — 理想的な V1 の規模は、最小限の MVP、完成した機能、プラットフォームのどれですか？ 最初の2つから1つを推奨してください。
- 目指す水準 — 早期の成果、戦略的な賭け、価値が積み上がる機能のどれですか？ また、「段階的な改善ではなく、価値を10倍に高めるものは何ですか？」
- 依存関係 — 既存の機能に影響しますか、または拡張しますか？ コードベース内の候補を挙げてください。
- 成功基準 — 成功したと、どのように判断しますか？
方向性を定める
理解が十分に深まったら、次の手順に進みます。
- トレードオフを添えて2〜3個のアプローチを提案し、推奨案とその理由を最初に示します。
- 複雑さに応じたセクションに分けて方向性を提示します（簡潔な内容なら数文、複雑な内容なら200〜300語程度）。次に進む前に、それぞれについてユーザーの確認を得ます。
- 議論を通じて明確になった用語は、その場で
CONTEXT.mdに記録します。3要素のゲートを通過した、後戻りが難しい決定は ADR として記録します。
成果物の保存先
会話そのものが成果物です。複製せず、適切な場所に振り分けてください。
- プロダクトレベルのアイデア（市場に関する質問、解決策の方向性が未確定） →
write-idea（docs/specs/<slug>/_idea.mdを生成します）。 - 仕様を作成する準備が整った機能 →
write-prd（この会話を取りまとめます。再度ヒアリングは行いません）。 - リファクタリングまたはバグ修正（プロダクトの動作に変更がないもの） →
write-techspecを直接実行します。最小限の_prd.mdを含む仕様フォルダーを作成し、プロダクトに関するヒアリングは行いません。 - 些細で内容が明確な変更（1行の修正、誤字、設定の微調整） → 仕様フォルダーは作成せず、直接実装します。その旨を明示してください。
リポジトリに docs/agents/spec-routing.md がある場合は、そのルーティングテーブルに従ってください。このリストの内容は、プロジェクトごとにそのファイルが正式版となります。
別の設計ドキュメントは作成しないでください。成果物は仕様作成パイプラインのファイル（_idea.md、_prd.md）に記録します。
主な原則
一度に質問するのは1つ · 選択式を優先する · 質問する前に調査する · YAGNIを徹底する · 決定する前に必ず代替案を提示する · 段階的に検証する · 回答によって以前の前提が崩れた場合は、前の段階に戻って検討する準備をしておく。