feature-orchestrator

Feature Orchestrator

このスキルは、2セッションで構成されるワークフローのセッション1を実行します。セッション1は考える段階です。ユーザーが何を、なぜ作るのかを決めるのを支援します。セッション2は作る段階です。新しいセッションが作成済みのプロンプトを受け取り、現在のリポジトリを調査して計画を立て、成果を届けます。

この分割があるのは、計画と実装が同じコンテキストウィンドウと注意力を奪い合うからです。セッション1では自由に検討し、考えを変えることができます。セッション2は、確定した決定事項だけを持って新たに開始します。そのため、セッション1が生み出す最も価値ある成果物は、苦労して得た決定事項をすべて正確に伝えるプロンプトです。綿密な計画の重要性はそれより低くなります。

最初のアイデアから急いでプロンプトに進まないでください。会話も作業の一部です。

境界

• セッション1では実装しないでください。リポジトリの指示、コード、テスト、依存関係、ドキュメントは自由に読めますが、ソース、設定、依存関係、スキーマ、テストは変更しないでください。ユーザーが求めた場合は、ローカルブランチの作成など、元に戻せるワークフロー操作を行ってもかまいません。
• 技術的に深く掘り下げることは歓迎します。有力な API、データモデル、フロー、リスク、候補となるマイルストーンは、機能を固めるのに役立ちます。ただし、そのいずれもセッション2の計画にはなりません。コードが変わっている可能性があり、セッション1の見解も部分的なものなので、セッション2はリポジトリを再調査し、自ら計画を立てます。
• プロダクトの曖昧さによって動作やスコープが大きく変わる場合は、質問してください。暗黙のうちに決めないでください。
• ユーザーが保存を求めない限り、議論、要約、プロンプトは会話内に留めてください。

モデルの役割構成を決める

セッション2では、次の4つの役割を使用します。

• Lead：セッション2のメインエージェントです。オーケストレーションと統合を行い、最終確認を実施します。モデルはユーザーがセッション2を起動するときに使うものなので、役割構成には含まれません。
• Implementer：範囲を限定したコード変更や修正を行うサブエージェントです。
• Researcher：ドキュメントの確認、API の調査、読み取り専用の探索を行うサブエージェントです。セッション1でも使用します。
• Reviewer：統合された変更をレビューする、独立した読み取り専用のサブエージェントです。

ユーザーが、3種類のサブエージェントの役割それぞれについてモデルと作業強度を選びます。セッション2では、作業に応じて各役割のエージェントを必要な数だけ実行します。

プロンプトをまとめるたびに、引き継ぎの時点でモデルの役割構成を尋ねてください。議論の最中には尋ねないでください。セッション1自身の調査用サブエージェントでは、環境にプリセットされた Researcher を使用します。質問の仕方（役割ごとに1つの質問をし、推奨オプションを最初に示す）、利用可能状況の確認方法、レビューの独立性を保つ方法については、references/model-roster.md を参照してください。

会話を通じて進める

探索する

その時点の質問に、適切な深さで答えてください。毎回の返信でワークフロー全体を強引に進めないでください。会話を通じて、次の点を明らかにします。

• プロダクトが現在どのような機能を持つか。
• この機能を誰が使い、どのような成果を必要としているか。
• 想定されるユーザージャーニー。
• 現時点でのスコープと、後回しにするもの。
• このリポジトリに適した技術スタックとアーキテクチャ。
• 失敗時の動作、権限、競合状態、データの所有権、コスト、運用性など、重要となる事項。

リポジトリで確認した事実、現在の外部情報、ユーザーの決定、推奨事項、前提を区別できるようにしてください。最終プロンプトでの重みは、それぞれ異なります。

決定に影響する場合は調査する

• 独立した調査、ドキュメントの確認、コードベースの探索は Researcher サブエージェントに委任してください。質問が独立している場合は、並行して実行します。
• 各サブエージェントには、範囲を限定した質問、その質問が重要な理由、求める回答の形式を伝えてください。たとえば、ファイルの内容を丸ごと貼るのではなく、file:line 形式の根拠やソースへのリンクを添えた結論を求めます。
• リポジトリ内の根拠と、最新の一次情報を優先してください。古くなる可能性のある主張にはリンクを付けてください。
• 調査結果は会話に取り入れてください。生のメモを貼り付けたり、見た目を整えるためだけに調査したりしないでください。

ユーザーとすり合わせる

ユーザーがスコープを絞ったり、複雑さを避けたり、優先順位を変えたり、異議を唱えたりすることを想定してください。以前の決定と照らし合わせて、それぞれの修正を反映してください。最初からやり直したり、以前の提案を擁護したりしないでください。

決定事項を頭の中で記録しておきます。

• 受け入れた動作
• 却下または保留にしたスコープ
• 選択した技術と、意図的に除外したもの
• 確定した不変条件
• 未解決の質問
• 検証と納品に関する期待

毎回それを読み上げる必要はありません。後の回答や最終プロンプトに一貫性を持たせるために活用してください。5ターン目に修正された内容を30ターン目まで覚えておくのは難しいものです。

求められたら要約する

ユーザーから概要、進行計画、または振り返りを求められたら、現時点での決定事項をすべてまとめてください。複雑な機能の場合は、技術スタック、UX、データモデル、ワークフロー、認可の境界、障害からの復旧、競合状態への対策、テスト、妥当な実装順序を含めます。ユーザーが確定するまでは、いつでも変更できる状態にしておきます。

求められた場合のみプロンプトを作成する

ユーザーから求められた場合、または計画が確定したことが明確に示された場合に限り、Session 2 のプロンプトを作成してください。

1. references/model-roster.md を読み、Implementer、Researcher、Reviewer それぞれのモデルと effort をユーザーに確認します。回答を得るまで、草案は作成しません。
2. references/execution-prompt-contract.md を読み、機能に合わせて調整します。
3. 時間をかけて得られた重要な決定事項を、具体的な表現で保持します。「ベストプラクティスに従う」では、会話を通じて確立した情報が失われます。
4. 重要な選択が未決定の場合は、ユーザーに確認します。未決定事項を指示のように装ってはいけません。

プロンプトには、次のワークフロー上の選択を含めてください。

• Lead は新しいリポジトリを確認して計画を立て、その後、承認を待たずに実装します。
• すべてのサブエージェントは、担当ロールで選択されたモデルとオプションを厳密に使用します。Session 2 にモデル選択を委ねてはいけません。Lead は起動時の設定で動作します。
• Session 2 は複数のサブエージェントを使います。独立した調査項目には並列の Researcher を、独立した作業範囲には並列の Implementer を、異なる観点でのレビューには複数の Reviewer を割り当てます。
• 作業の構成は Lead が選びます。独立した作業は並列化し、依存する作業は段階的に進め、委任しても効果がない作業は直接実装します。エージェント数に恣意的な上限を設けず、目的なく大量のエージェントを使うことも避けます。
• すべてのサブエージェントには、目標、重要性、関連する決定事項、担当ファイル、隣接作業とのインターフェース、完了条件、実行すべきチェックを含む、十分な文脈を持たせた説明を渡します。Implementer には、リポジトリを共有しており、互いの変更やユーザーの変更を元に戻してはならないことを伝えます。
• Lead は進捗ファイルを維持し、計画、状況、決定事項をコンテキストの圧縮後も保持します。
• 実装中に対象を絞ったチェックを実行します。レビュー前に、機能全体の検証を完了させます。
• フロントエンドまたはブラウザーで確認できる作業では、Session 2 のビジョンとして組み込みブラウザーを使います。UI に触れるすべてのエージェントは、最初の変更から「書く → 確認する → 操作する → 修正する」のループを実施します。最後に一度だけ検証する方法は使いません。
• Reviewer はそれぞれ異なるリスクの観点からレビューします。Lead は各指摘を確認してから修正を決定し、受け入れた修正を Implementer に引き渡します。レビューと修正のサイクルは最大2回です。
• Session 2 は、根拠を示した PR 提案を準備します。明示的な承認なしに push や PR の作成を行いません。実際の PR 数を使った、正確な許可確認の質問で終了します。

納品と PR の検討

機能を複数の PR に分けるメリットがある場合は、判明している依存関係とともに、成果を中心とした暫定的な分割案を含めます。Session 2 には、実際の変更グラフに基づいてその案を検証させます。テストは、検証対象の動作と同じ PR に含めます。作業ストリームと PR の境界は別の概念です。安全でない場合は、提案した分割を無理に適用してはいけません。

出力

短い導入文と、コピーしてすぐ使えるプロンプトを1つ返します。ユーザーの注意を要する前提がある場合を除き、仕様をプロンプトの外で繰り返さないでください。

最終セルフチェック

プロンプトを返す前に、以下を確認してください。

• Session 1では何も実装されておらず、Session 2の最終計画として提案が提示されていないこと。
• 後からのすべての修正とスコープ縮小が反映されていること。
• 事実、決定事項、推奨事項、前提が区別できること。
• 動作、不変条件、証明要件がこの機能に固有であること。
• 実装担当者、調査担当者、レビュー担当者に、ユーザーが選択または確認した正確かつ利用可能な設定と、正直な制限事項が記載されていること。
• 最後の質問より前にプッシュやPRの作成を許可する文がないこと。