brainstorm

アイデアをデザインにまとめる

概要

自然で協調的な対話を通じて、アイデアを具体的なデザインと仕様にまとめます。

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

プロセス

アイデアを理解する：

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

アプローチを検討する：

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

デザインを提示する：

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

デザインの後

ユーザーが仕様書のドラフトファイルを提供した場合は、そのファイルを直接更新します。提供されていない場合は、/add-task スキルを使って、採用するアプローチのタスクファイルを作成します。

重要：仕様書ファイルでは、採用するアプローチをセクションに分け、## Initial User Prompt -> ### Requirements セクションに、## Description セクションより前に記述します。Description は後の段階で記入します。

タスクファイルを記入したら、/clear を実行し、その後 /plan-task <task-file-path> を使ってタスクファイルをさらに整えるよう提案します。

基本原則

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