diverse-plan

多様な計画

モデルを選択する前に、ブランチを選択します。現在のコーディネーターでブランチの前提と必要なレビュー対象を選択します。選択したブランチやレビュアーに作業を割り当てる前に、shared/references/model-preview.md を使用して、承認済みルートのスナップショットを確定します。

代替案によって実装の判断が変わり得る場合にのみ、これを使用します。これは models-consensus とは別のものです。ユーザーが選んだのは計画演習であり、評議会ではありません。このスキルから評議会を呼び出してはいけません。

成果

実行可能な計画を1つ提示します。選択したアプローチ、却下した代替案、ファイル、テスト、リスク、使用した有効な担当枠を明記します。ブランチが有用なのは、実質的に異なる前提を検討する場合に限られます。

ルーティング

選択したワーカーについて、 task-shaped-model-routing.md、 model-roster.md、および host-model-execution.md を読み、スナップショットの役割を割り当てます。従来の担当枠名や固定されたモデル ID ではなく、選択したセマンティックルートを使用します。

選択した各ブランチを shared/model-routing.json の deep-analysis、architecture、または technical-analysis に割り当てます。precision-review は、特定のセマンティックリスクについて独立した批評が必要な場合に限り使用します。正確なルートを承認済みスナップショットに記録します。ブランチでは異なる前提を検討する必要があり、同じ概要をより多くの労力で繰り返してはいけません。

デフォルトでは、ブラインドブランチの担当枠を2つ使用します。未解決の境界、障害ケース、またはデリバリー上のトレードオフについて、別個のアプローチが必要な場合に限り、3つ目を追加します。モデルと労力は設定で指定し、このスキルではブランチの手順を定めます。

まず、アクティブなホストを通じて、スナップショットの正確なネイティブルートを使用します。各ブラインドブランチは、それぞれ独立した永続サブエージェント、またはサポートされているタスクコンテキストで開始します。ランナーは、外部モデルを使用する場合、またはネイティブルートでは承認済みの計画を満たせない場合に限り使用し、後続の批評や統合のターンに備えて、ランナー自身のセッションを記録します。選択した機能のみをプローブします。担当枠の忠実性を維持します。不足している担当枠は利用不可とし、黙って置き換えてはいけません。利用可能な、互いに異なるブランチ担当枠が2つある場合に限り続行します。この定足数を満たせない場合は、不足している前提条件と、単一モデルで進める to-prd パスを返します。

ルートの承認

ブランチの選択後、正確なルート表を提示します。表には、ブランチまたはレンズ、担当枠、現在のモデル、労力、役割、実行パス、呼び出し回数、および利用できないアクションを含めます。ブラインドブランチ、選択した批評、統合、および実行完全性チェックも含めます。この表を共有プレビューに使用し、判断ルールを一度だけ適用します。選択していないブランチや批評を開始してはいけません。承認済みスナップショットを計画成果物とともに記録し、そのルートのみを使用します。

ワークフロー

1. 目標、範囲、制約、受け入れ条件、関連ファイル、および計画で決定すべき内容を含む、中立的な概要を1つ作成します。回答の違いによって計画が変わる場合に限り、質問を1つだけします。
2. 同じ概要を使ってブラインドブランチを開始します。各ブランチには、最小限の実現可能な変更、最もすっきりした設計、または最も堅牢な障害対応のうち、1つの前提を割り当てます。それぞれがアプローチ、ファイル、トレードオフ、リスク、テスト、およびロールバック地点を提示します。後続の批評や返信でも、そのブランチのコンテキストを維持します。新しい開始コンテキストは別のブランチです。
3. 受け入れ条件に照らしてブランチを比較します。関連するエンジニアリングレンズのみを実行します。各批評では、最も優れた点、実質的な弱点、および具体的なテストまたは確認事項を特定します。
4. 記録を1つの計画に統合します。採用した各要素は、ブランチまたは解決済みの批評まで追跡できるようにします。実質的な未解決の意見の相違は、リスクまたは未解決の質問として残します。
5. 範囲を限定した実行完全性チェックを1回行います。重大な抜けが明らかになった場合に限り、計画を1回修正します。終わりのない計画ループを作ってはいけません。

統合と強化

承認済みスナップショットの統合ルートを使用してください。計画の中核を選び、検証済みの改善点を取り込み、最有力の代替案が採用されなかった理由を記録します。統合のコンテキストは、それぞれのブラインドな初期案と分けてください。選択したルートを利用できない場合は、停止して不足しているルートを報告するか、ユーザーが承認した代替案のみを使用してください。

実行の完全性チェック

承認済みスナップショットの実装レビュー・ルートを使用し、実装者が設計上の判断を独自に考案せずに計画に従えるかを確認してください。対象範囲、ファイルの配置、受け入れ基準、コマンド、テスト、ロールアウトのリスク、ロールバックを確認します。重大な不足が1つある場合は、対象を絞った修正を1回行います。それ以外の場合は停止してください。

出力

以下を提示してください。

1. 変更内容と選択したアプローチ。
2. 検討したアプローチと、決め手となったトレードオフ。
3. 実装手順（順序付き）、ファイル、テスト、検証。
4. リスク、ロールバック、未解決の質問。
5. 有効なレシート、利用できない席、フォールバックを含む、席とレンズの表。

ユーザーが求めた場合にのみ、成果物を作成してください。承認済みの計画を to-prd に渡してワークフローの承認済みプロダクト記録とし、その後 to-tasks でそのPRDをタスクに分割します。ここでは実装しないでください。