sdd:brainstorm

アイデアをデザインに落とし込む

概要

自然な対話を通じて、アイデアを具体的なデザインや仕様に仕上げるのを支援します。

まず現在のプロジェクトの状況を把握し、アイデアを具体化するために質問を一つずつします。何を作るのか理解できたら、デザインを200～300語の短いセクションに分けて提示し、各セクションの後に、ここまでの内容で問題ないか確認します。

プロセス

アイデアを理解する：

• まず現在のプロジェクトの状態（ファイル、ドキュメント、最近のコミット）を確認します
• アイデアを具体化するために質問を一つずつします
• 可能であれば選択式の質問を優先しますが、自由回答形式でもかまいません
• 1回のメッセージにつき質問は一つだけにします。さらに掘り下げる必要がある場合は、複数の質問に分けます
• 目的、制約、成功基準の把握に重点を置きます

アプローチを検討する：

• トレードオフを含めて6つのアプローチを生成します。各アプローチには、説明と数値の確率を含めてください。以下のように、[確率分布全体／分布の裾]からランダムに回答をサンプリングしてください。
  • 最初の3つの回答は、高い確率（0.80超）を目指します
  • 残りの3つの回答は、多様性を重視します。解決策の空間の異なる領域を探り、各回答の確率が0.10未満になるようにします
• 推奨案とその理由を添え、会話形式で選択肢を提示します
• 推奨案を最初に示し、その理由を説明します

デザインを提示する：

• 何を作るのか理解できたと判断したら、デザインを提示します
• 200～300語のセクションに分けます
• 各セクションの後に、ここまでの内容で問題ないか確認します
• アーキテクチャ、コンポーネント、データフロー、エラー処理、テストを扱います
• 不明点があれば、立ち戻って確認します

デザインの完成後

ドキュメント作成：

• 検証済みのデザインを .specs/plans/<topic>.design.md に書き込みます
• 利用可能であれば、docs:write-concisely スキルを使用します
• デザインドキュメントを Git にコミットします

実装（継続する場合）：

• 「実装の準備を始めますか？」と質問します
• git:create-worktree を使用して、隔離されたワークスペースを作成します
• sdd:add-task を使用して、対象のアプローチ用のタスクファイルを作成します

重要な原則

• 質問は一つずつ - 一度に複数の質問をして、相手を困らせないようにします
• 選択式を優先 - 可能であれば、自由回答形式より答えやすい形式にします
• YAGNIを徹底 - すべてのデザインから不要な機能を取り除きます
• 代替案を検討 - 最終決定の前に、常に2～3つのアプローチを提示します
• 段階的に検証 - デザインをセクションごとに提示し、それぞれを検証します
• 柔軟に対応 - 不明点があれば、立ち戻って確認します