brainstorm

ブレインストーミング

直接呼び出す場合は、まず shared/references/model-preview.md を使ってブランチを選択します。コーディネーターの作業と決定論的なコマンドは、呼び出し権限の範囲内で進めます。実際のワーカーブランチでは、承認済みのルートスナップショットを1つ使用します。ネストされた呼び出しではそれを再利用し、ルートの選択やワーカーの追加は行いません。

構築するかどうか、またどの方向を探るかを判断します。方法より先に理由を明らかにします。仕組みを選ぶ前に、問題を特定します。ユーザーのニーズとプロジェクトに基づく代替案を検討し、解決策の選択肢を広げます。本番コードや実装タスクは作成しません。

1. 問題を理解する

既存のコンテキストを活用し、関連するコード、ドキュメント、過去の決定を調査します。調査で答えられないことだけを尋ねます。誰が影響を受けるのか、現在何がうまくいっていないのか、なぜ重要なのか、どの制約が判断を左右するのかを確認します。新たな根拠がない限り、確定した決定を再検討しません。

2. 実現可能な方向性を比較する

現在のアプローチ、役に立つ最小限の変更、そして該当する場合は大きく異なる選択肢を比較します。期待される結果、コスト、主なリスクを示します。プロジェクトに関する主張には、この実行中に確認したファイルを引用します。前提と未検証の外部情報には、その旨を明記します。

アイデアを生成する場合は、references/idea-basis-contract.md を読みます。各アイデアには、情報源または明示的な推論の根拠が必要です。ユーザーがある領域を評価できない場合は、references/blindspot-pass.md を読みます。そこに記載された領域確認は、情報に基づく意思決定の一連の作業より先に行います。

明示的に評議会が求められた場合に限り、models-consensus を使用します。そのスキルが、評議会に関する個別の承認、ルーティング、ディスパッチ、成果物を管理します。中立的な問題説明を渡し、そのレポートをここで使用します。通常の選択肢を検討するために評議会を設けてはいけません。

3. 方向性を決める

1つの選択肢を推奨し、重要なトレードオフを説明します。ユーザーには、その方向性を確認するか変更するかを尋ねます。重要な異議には対応します。選択肢や検討ラウンドの数を固定しません。

4. 結論を返す

理由、提案するスコープ、対象外の事項、未解決の決定事項、根拠とともに、BUILD、DEFER、REDUCE SCOPE、または REJECT を示します。DEFER の場合は、検討を再開すべき出来事を明記します。測定に基づく根拠がない限り、数値で確信度を示すことは避けます。

BUILD または REDUCE SCOPE の場合は、合意した方向性を interview-me に引き継ぎ、to-prd に進む前に要件を確定します。その段階へ進むのは、ユーザーの依頼の範囲内に限ります。DEFER または REJECT の場合は、そこで終了します。結論が受け入れ条件となるため、この段階で実装計画を作成する必要はありません。