brainstorming

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

概要

自然な共同対話を通じて、アイデアを完成度の高い設計と仕様へ仕上げるお手伝いをします。

まず現在のプロジェクトの状況を把握し、その後質問を一度に1つずつ投げかけてアイデアを磨き上げます。何を作るのかが理解できたら、設計を200〜300語程度の小さなセクションに分けて提示し、各セクションの後に、ここまでの内容が正しいかどうかを確認します。

プロセス

アイデアの理解:

• まず現在のプロジェクトの状態を確認します（ファイル、ドキュメント、最近のコミット）
• アイデアを磨くために、質問は一度に1つずつ行います
• 可能な場合は選択式の質問を優先しますが、自由記述式の質問でも構いません
• 1つのメッセージにつき質問は1つだけにします。ある話題をさらに掘り下げる必要がある場合は、複数の質問に分割します
• 目的、制約、成功基準の理解に焦点を当てます

アプローチの検討:

• トレードオフを伴う2〜3つの異なるアプローチを提案します
• 推奨案と理由を添えて、選択肢を会話形式で提示します
• 推奨するオプションを先頭に示し、その理由を説明します

設計の提示:

• 何を作るのかを十分に理解できたと判断したら、設計を提示します
• 200〜300語のセクションに分割します
• 各セクションの後に、ここまでの内容が正しいかどうかを確認します
• 対象は、アーキテクチャ、コンポーネント、データフロー、エラー処理、テストです
• 意味が通らない箇所があれば、いつでも立ち戻って明確化する準備をしておきます

設計の後に

ドキュメント化:

• 検証済みの設計を docs/plans/YYYY-MM-DD-<topic>-design.md に書き出します
• 利用可能な場合は、elements-of-style:writing-clearly-and-concisely スキルを使用します
• 設計ドキュメントを git にコミットします

実装（続行する場合）:

• 「実装の準備を始めてもよろしいですか？」と確認します
• superpowers:using-git-worktrees を使用して、独立したワークスペースを作成します
• superpowers:writing-plans を使用して、詳細な実装計画を作成します

主要な原則

• 一度に質問は1つ - 複数の質問で相手を圧倒しないようにします
• 選択式を優先 - 可能な場合は、自由記述式よりも答えやすい形にします
• YAGNIを徹底 - すべての設計から不要な機能を取り除きます
• 代替案を検討 - 決定する前に、必ず2〜3つのアプローチを提案します
• 段階的な検証 - 設計をセクションごとに提示し、それぞれを検証します
• 柔軟であること - 意味が通らない箇所があれば、立ち戻って明確化します