workflow-brainstorm

アイデアをデザインに落とし込むブレインストーミング

目標

「漠然としたアイデアや要件」を実行可能なデザインと仕様に変換し、チャット内だけで終わらせず、再利用可能なファイルとして成果物を作成します。

主な要件：質問は一度に1つだけにしてください。複雑なテーマの場合は、チェックリストを一度に提示するのではなく、複数回に分けて質疑応答を行います。

基本プロセス（必ず従うこと）

0）まずプロジェクトの状況を確認する（リポジトリがある場合は必須）

質問する前に、以下を手早く確認します。

• 主なドキュメント：README.md、docs/、design-system.md（存在する場合）
• 技術スタックと制約：package.json／Cargo.toml／pyproject.toml など
• 構成の概要：トップレベルのディレクトリ、主要モジュール
• 最近の変更：git log -n 10 --oneline（Git リポジトリの場合）

確認した内容と、制約となりそうな点を簡潔にまとめて出力します（まだデザインには着手しません）。

1）アイデアを把握する（一度に1つ質問）

目的は、必要最小限の情報（目的／制約／成功基準）を集めることです。

ルール：

• 各メッセージで尋ねる質問は1つだけ
• ユーザーの認知負荷を軽減するため、選択式を優先し、必要な場合にのみ自由回答形式を使う
• まず方向性を決める質問（目標／成功基準／対象外の事項）を尋ね、その後に詳細を確認する

2）解決策を検討する（2～3案とトレードオフ）

要件を把握した後：

• 2～3案（A／B／C）を提示する
• 各案のトレードオフ（複雑さ／リスク／反復の速さ／長期的なコスト）を説明する
• 推奨案を最初に示し、その理由を説明する

3）デザインを出力する（200～300語ずつ出力し、各セグメントで確認する）

実施内容を十分に把握できたら、デザイン仕様書の出力を開始します。

要件：

• 200～300語程度のセグメントに分けて出力する
• 各セグメントの最後に確認を求める。例：「この内容でよさそうですか？」
• デザインには少なくとも以下を含める：
  • アーキテクチャとモジュールの境界
  • 中核となるデータフロー（入力 → 処理 → 出力）
  • エラー処理とエッジケース
  • テストおよび検証の方針（最小限の実用セット）

ユーザーがセグメントに同意しない場合は、質問または選択肢の提示に戻って詳細を確認します。先に進めてはいけません。

成果物と永続化（強く推奨）

デザインドキュメントの作成

可能であれば実行ディレクトリに作成します（成果物を優先）：

• run_dir/evidence/YYYY-MM-DD-<topic>-design.md

run_dir がなく、repo_root がある場合：

• runs/brainstorm/active/<run_id>/ を作成し、evidence/ にデザインを書き込みます

注：ファイルの書き込みは書き込み操作です。対象がユーザーのプロジェクトリポジトリの場合、書き込む前に「プロジェクトに保存してもよいですか？」と確認してください。

実装に進む（任意）

デザインの確認後、次のステップを選べるように1つ質問します。

1. そのまま実装に進む（workflow-ship-faster または workflow-feature-shipper を推奨）
2. まず実装計画を書く（run_dir/tasks.md にチェックリスト項目として保存し、確認を待つ）
3. 先に調査／コードの読み込みを行う（run_dir/evidence/parallel/<task-name>/ に分割し、並行して進める）

重要な原則

• 一度に質問は1つだけ：1つのメッセージで5つの質問をしない
• 選択式を優先：ユーザーがより速く、効果的に回答できるようにする
• YAGNI：まだ必要のない機能は、デザインから積極的に取り除く
• 段階的な検証：デザインをセグメントごとに出力し、それぞれ確認する