orchestrate-omp

OMP でオーケストレーションする

本格的な作業がバックグラウンドで進んでいる間も、ユーザーへの対応を続けます。ルートコーディネーターは、計画、ユーザーとのやり取り、承認、スコープ、統合、最終確認を担当します。

1. 方針を定める

1. 完了条件と、最終成果物または判断を明確にします。
2. 独立した調査、専門家によるレビュー、または担当範囲が明確な実装のみを分割します。密接に関連する作業は1つのセッションにまとめます。
3. 作業を振り分ける前に、担当者ごとの主担当範囲を分け、共通の取り決めを明示します。ファイルが重複する可能性を避けるためだけに、有用な並行作業を重複調査したり、順番に実施したりしないでください。
4. 外部への副作用を伴う操作と承認判断は、ルートが担当します。

2. エージェントを選ぶ

稼働中の task ツールに表示される正確な名前を使用してください。エージェント一覧は、このツールの内容を正とします。現在の OMP の一覧は次のとおりです。

作業	エージェント	指定可能な場合の作業量
読み取り専用の限定的なコードベース調査	scout	lo
定型的で範囲が限定された実装	agent を省略してデフォルトのワーカーを使用	med
難易度が高い、または曖昧な実装	agent を省略してデフォルトのワーカーを使用	hi
機械的な編集やデータ収集	sonic	lo
UI/UX の実装またはレビュー	agent を省略してデフォルトのワーカーを使用し、指示に設計の専門性を記載	med または hi
コード品質の判定	reviewer	med または hi
セキュリティの判定	security-reviewer	hi
外部ライブラリや API の調査	librarian	lo または med

稼働中のタスクスキーマで effort が指定可能な場合は、割り当てに合わせて設定します。限定的な質問には lo、定型作業には med、曖昧さや影響の大きさを考慮する場合には hi を指定します。指定できない場合は、選択したエージェントに設定されたモデルの役割に従い、利用できないフィールドは渡さないでください。/skill:setup-pstack でこれらの役割を設定できます。

稼働中の一覧にある読み取り専用およびブロッキングのマーカーを尊重してください。デフォルトのワーカー名を明示的に渡してはいけません。

3. 作業を振り分ける

1. 稼働中のスキーマで tasks[] が利用できる場合は、独立した作業者を1つのバッチにまとめ、共通の context を Goal、Constraints、Contract で構成します。利用できない場合は、context を渡さず、各タスク呼び出しで作業者を1人ずつ起動します。
2. 各項目には、32文字以内の安定した CamelCase の name、該当する場合は最も専門性の高い agent、単独で完結する task、作業量ではなく問題の自由度を示す solutionSpace を指定します。デフォルトのワーカーを使う場合は agent を省略します。稼働中のスキーマで effort が利用できる場合のみ追加します。
3. 各割り当ては Target、Change、Acceptance で構成します。必須のリポジトリの状態、決定事項、制約、依存関係を記載してください。子エージェントは会話履歴を引き継がずに開始します。
4. すべての実装担当者に、書き込み可能な範囲を正確に指定します。稼働中のスキーマで isolated が利用できる場合は、分離したワークスペースが必要な並行作業者に isolated: true を設定し、返されたメタデータを確認して、変更が適用されたのか成果物として保持されたのかを把握します。
5. 通常のワーカーには次のように伝えます。この割り当てを直接完了してください。task を呼び出したり、サブエージェントを起動したりしないでください。 そのワーカーを明示的にコーディネーターにする割り当ての場合に限り、ネストした委任を許可します。デフォルトでは task.maxRecursionDepth は 2 なので、コーディネーターの子エージェントが最終階層になります。
6. ワーカーには、プロジェクト全体のフォーマット、リント、テストスイートの実行をスキップするよう伝えてください。統合後にルートが共有の検証を一度実行します。

大きなコンテキストは割り当てに重複して記載せず、local://<path> で参照するローカルファイルに格納します。

コーディネーターが機械可読な結果を必要とし、稼働中のスキーマで利用できる場合に限り、outputSchema を使用します。不正な出力を警告付きで返さず、失敗扱いにする必要がある場合は、schemaMode: "strict" を設定します。

4. 調整

• 結果は自動的に配信されます。ポーリングするのではなく、ユーザーメッセージへの対応と独立したルート作業を続けてください。ルートが本当に行き詰まっている場合にのみ、waitを使用してください。
• read proc://は実行中のジョブを一覧表示し、read proc://<id>は配信結果を消費せずにジョブを確認します。
• write agent://<id>は、範囲を限定した修正、回答、または次の連携フェーズを送信し、待機中のセッションを再開します。agent://allはブロードキャストします。兄弟エージェント間のメッセージが交渉による確認ではなく目的に沿ったものになるよう、共有コンテキストに依存関係の対象を明記してください。
• write proc://<id>/killは、古くなった作業や置き換えられた作業をキャンセルします。
• 完全な結果はagent://<id>から読み取ってください。報告が不完全、または疑わしい場合は、history://<id>を使用してください。
• ジョブの完了とは、子エージェントが正常に結果を返したことを意味します。その成果物が承認されたことを意味するものではありません。

5. 引き継ぎ

ワーカーの最終メッセージが引き継ぎとなり、情報をツリーの上位に伝える手段はこれだけです。すべてのワーカーに同じ形式を求めてください。ステータス（PASS、ISSUES、BLOCKED）、ブランチまたは成果物のパス、実施内容、注記と逸脱事項、推奨するフォローアップを含めます。

• ワーカーの言葉をそのまま保ってください。切り詰められたプレビューを言い換えて計画に反映するのではなく、全文はagent://<id>から読み取ってください。
• BLOCKEDは、あるタスクが行き詰まったことを示すだけで、ツリー全体の行き詰まりではありません。フォローアップメッセージで再試行、修正、または明確化を行い、ほかの作業は進めてください。
• すべての分岐で作業を続けると労力が無駄になる場合に限り、ツリー全体を停止してください。たとえば、ベースの破損、契約の誤り、共有依存関係の失敗などです。
• 報告なしに終了した子エージェントは成功ではなく、情報の欠落です。明示的に記録し、再起動するか判断してください。
• 注記のセクションを最も重要な部分として扱ってください。逸脱や懸念はすべてタスク候補です。また、スコープが不明確という指摘は、ブリーフが不十分だった証拠です。

6. 統合

1. 必要な参加者全員から結果を受け取るか、キャンセルまたは欠落を記録します。
2. 主張された各成果物を確認し、宣言された担当範囲と契約に照らして競合を調整します。
3. 統合後のヘッドで、影響を受ける検証と実際のユーザー経路をルートから実行します。
4. エージェント識別子、承認された調査結果または変更、検証の証拠、未解決の欠落事項を含め、簡潔な結果を1つ返します。

返されたメタデータで裏付けられる場合に限り、モデルまたはバックエンドの多様性を主張してください。