brainstorm

ブレインストーミング

概要

このスキルを使うと、構造化された対話を通じて、粗削りなアイデアを明確でレビュー可能な設計成果物にまとめられます。

目標は次のとおりです。

1. 要件と制約を明確にする
2. トレードオフを踏まえて代替案を検討する
3. 具体的で検証済みの設計概要を成果物として作成するか、プランニングに引き継ぐ

ワークフロー

ステップ 1：プロジェクトのコンテキストを収集する

現在のアイデアに関連するプロジェクトのコンテキストだけを読み込みます。

• docs/SUMMARY.md が存在する場合は、最初に読みます。
• タスクに関連する詳細ドキュメントだけを読み込みます。
• 実装規約については、Code Standard ドキュメントを優先します。
• ドキュメントとコードまたはユーザーの意図が矛盾する場合は、大規模な変更を行う前に、利用可能な対話型入力／質問ツールを使います。

また、アイデアに関連する主要な実装ファイルも確認し、既存のアーキテクチャ、依存関係、規約による制約を把握します。

この確認は対象を絞って行います。現在のアイデアに必要な情報だけを収集します。

ステップ 2：要件を明確にする

対話型入力／質問ツールを使い、曖昧さを解消するための的を絞った質問を順に行います。

• 次の点に焦点を当てます。
  • 目的とユーザーにとっての価値
  • スコープの境界
  • 制約（技術面、UX、パフォーマンス、スケジュール）
  • 成功基準
  • 対象外の事項

実装の詳細に早く踏み込みすぎないでください。

ステップ 3：アプローチを検討する

実現可能なアプローチを 2～5 個提案します。

各アプローチには、次の内容を含めます。

• 短い概要
• メリット
• デメリット／リスク
• 複雑さの見積もり
• 推奨される利用条件

まず推奨案を提示し、それがプロジェクトのコンテキストと制約に最も適している理由を説明します。

すべてのアプローチを提示した後、対話型入力／質問ツールを使って、ユーザーが希望するアプローチを選べるようにします。概要の選択肢を列挙します。例：

• アプローチ A、短い概要
• アプローチ B、短い概要
• アプローチ C、短い概要
• その他（指定してください）

ユーザーの判断を助けるため、推奨案にはタグを付けます。

ステップ 4：設計を段階的に提示する

ユーザーが選択した後、次のセクションに分けて設計を段階的に提示します。

• 1. 基盤 - 問題の整理、目標、提案するアーキテクチャ／フロー。
• 2. 技術的な詳細 - データモデル、インターフェース、エラー処理、エッジケース、リスク。
• 3. 提供 - テスト／検証戦略とリリース時の考慮事項（該当する場合）。

提示後、すぐに入力／質問ツールを使って、次のいずれかを行うか尋ねます。

1. 次のステップに進む
2. 設計を調整する（入力必須）

ステップ 5：最後に次のアクションを確認する

ユーザーと要件を検討し、設計を検証した後、次のアクションを決定します。

入力／質問ツールを使って、次の 3 つの大まかな次のアクションをユーザーに提示します。

• "Write plan immediately" - 成果物のステップを省略し、図解を含む write-plan の引き継ぎに直接進みます。
• "Write artifacts" - ステップ 6 で説明するブレインストーミング文書の作成を続けます。
• "Implement immediately" - 設計が明確でリスクが低い場合、成果物とプランニングの両方を省略して、すぐに実装へ進めます。
• "End session" - セッションを終了します。ここまでの会話で、現時点で十分な知見が得られています。

ステップ 6（任意）：ブレインストーミング成果物を作成する

このステップを実行するのは、ステップ 5 でユーザーが明示的に「Write artifacts」を選択した場合のみです。

標準の場所に結果を保存します。

• ディレクトリ：docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/
• メインファイル（必須）：docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/SUMMARY.md
• 任意の補足ファイル：
  • docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/section-01-<slug>.md
  • docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/section-02-<slug>.md
  • など

SUMMARY.md の形式は、references/summary-template.md 内のテンプレートに厳密に従います。

成果物のドラフトができたら、再び入力／質問ツールを使って、次の選択肢から検証を行います。

• "Write plan with current artifacts, context"
• "End session - artifacts are sufficient for now"
• "Need changes"（自由記述）- フィードバックを収集し、成果物を修正してから、再度確認します。

ルール

• ブレインストーミングのセッションでは、本番コードの作成や実装の変更を行わないでください。
• やり取りは簡潔かつ反復的に進め、各ステップを同じセッション内で実行してください。
• 不確かな場合は、網羅性より明確さを優先し、追加の質問をしてください。
• すべての提案を、プロジェクトのドキュメントや標準に沿わせてください。
• 前提を明示し、黙って推測しないでください。
• コーディングの前に考える： 前提を明示してください。解釈が複数ある場合は、黙って一つを選ばず、候補を提示してください。より簡単な方法がある場合はそれを伝え、必要に応じて異議を唱えてください。
• 成果物はすべて、現在のセッションと同じ言語で作成してください。