フローブレインストーミング - 要求のブレインストーミング

概要

ユーザーの曖昧なアイデアを明確な設計仕様に変換し、自然な対話を通じて元の意図を捉えます。

核心原則: 要求の元の意図は開発プロセス全体の「北極星」であり、後続の各段階で逸脱していないか追跡および検証できる必要があります。

鉄の掟

NO FLOW EXECUTION WITHOUT BRAINSTORM ALIGNMENT

後続の各 flow-* 段階を開始する前に、BRAINSTORM.md との一致を確認する必要があります。

プロセス

フェーズ 1: アイデアの理解

一度に 1 つの質問をし、複数の質問でユーザーを圧倒しないでください。

1. プロジェクトの現状を確認します（ファイル、ドキュメント、最近のコミット）。
2. 質問をしてアイデアを具体化します。
   • 優先的に多肢選択式を使用します（回答しやすい）。
   • 1 つのメッセージで 1 つの質問のみをします。
   • トピックをさらに深く掘り下げる必要がある場合は、複数の質問に分割します。
3. 理解に焦点を当てます: 目的、制約、成功基準

質問の例:

この要求は主にどのような問題を解決しますか？
A) 新機能の追加
B) 既存の問題の修正
C) パフォーマンスの最適化
D) リファクタリング/技術的負債

フェーズ 2: アプローチの検討

• 2〜3 種類の異なる案を提示し、トレードオフを説明します。
• 推奨案とその理由を示します。
• ユーザーに意思決定をさせます。

案の提示形式:

### 案 A: {名称} ⭐ 推奨

**説明**: ...
**利点**: ...
**欠点**: ...
**適用場面**: ...

### 案 B: {名称}
...

フェーズ 3: 設計の提示

構築するものを理解したら：

1. 設計を段階的に提示します（各段落 200〜300 字）。
2. 各段落の後に、それが正しいかどうかを尋ねます。
3. アーキテクチャ、コンポーネント、データフロー、エラー処理、テストを網羅します。
4. 明確化のために戻る準備をしておきます。

フェーズ 4: ドキュメント化

検証済みの設計を BRAINSTORM.md に書き込みます。

devflow/requirements/${REQ}/BRAINSTORM.md

必ず含めるもの:

• 元の要求（ユーザーの言葉をそのまま、一字一句変えずに）
• 核心となる問題の定義
• 成功基準
• 制約条件
• 案の検討（2〜3 種類）
• 最終的な決定とその理由

主要な原則

合理化の防止

レッドフラグ - STOP

もしあなたが以下のような状況に気づいたら：

• 質問をせずに直接作業を開始している
• ユーザーが「何が欲しいかわかっている」と言ったので質問をやめた
• 案のトレードオフを記録せずに選択した
• BRAINSTORM.md を書かずに次の段階に進んだ

STOP。正しいプロセスに戻ってください。

CC-DevFlow との統合

flow-init 段階

Entry Gate:
  - REQ-ID とタイトルを解析
  - flow-brainstorming skill をトリガー

Brainstorm Phase:
  1. 質問をして要求を理解する（一度に 1 つ）
  2. 2〜3 種類の案を検討する
  3. 最終的な案を確認する
  4. BRAINSTORM.md を出力する

Exit Gate:
  - BRAINSTORM.md の存在を検証する
  - 必要な章が含まれていることを検証する

後続の flow-* 段階

Entry Gate に追加:
  step: Brainstorm Alignment Check
    - read: devflow/requirements/${REQ}/BRAINSTORM.md
    - verify:
        - 元の問題は依然として解決すべき目標か？
        - 選択された案は依然として適切か？
        - 制約条件は変化したか？
    - if 逸脱を発見した場合:
        - ask_user: "元の意図からの逸脱を発見しました。BRAINSTORM.md を更新しますか？"
        - action: 逸脱の理由を記録し、ドキュメントを更新する

出力テンプレート

.claude/docs/templates/BRAINSTORM_TEMPLATE.md を参照してください。

[PROTOCOL]: 変更時にこのヘッダーを更新し、その後 CLAUDE.md を確認してください。