mcpField
P
plan-arbiter

plan-arbiter

github.com/builderioエージェントワークフロー4.6k274 回インストール1 日前に更新
リポジトリ

plan-arbiter について

plan-arbiterは、複数の計画を比較し、実行可能な引き継ぎ内容にまとめる計画スキルです。提案を評価するエージェントやチーム向けに、相互レビューや検証項目を示し、実装を求められない限り読み取り専用で動作します。

主な機能

  1. 01計画を比較可能な主張に整理
  2. 02タスクやコードに照らしてレビュー
  3. 03選択・統合、または修正を依頼
  4. 04検証項目付きの引き継ぎを作成
  5. 05既定では読み取り専用の計画

活用シーン

  1. 01複数の実装案から選択
  2. 02実行前に前提とリスクを特定
  3. 03不採用案を含む引き継ぎを準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/builderio/skills --skill plan-arbiter

インストール後、Claude Code で/plan-arbiterを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlREADME.md

詳細

Plan Arbiter

競合する計画を、実行可能な一つの方針にまとめます。優れたアイデアを活かし、根拠の弱い前提を退け、寄せ集めではなく明確な引き継ぎを作成します。

ワークフロー

  1. 元となる計画を収集します。
  2. 各計画を、比較可能な主張に整理します。
  3. 計画同士、および実際のコードベースやタスクのコンテキストに照らして相互レビューします。
  4. 最善の計画を選ぶ、より優れたハイブリッド案にまとめる、または計画を修正に戻します。
  5. 検証ゲートと却下した代替案を含む、実行用の引き継ぎを一つ作成します。

ユーザーが判断後の実装を明示的に依頼しない限り、計画の策定は読み取り専用です。

元となる計画を収集する

計画は、貼り付けられたテキスト、ローカルファイル、セッション ID、トランスクリプトのパス、PR、コメント、ビジュアルプランのリンク、チャット履歴として受け取れます。可能な場合は元の成果物を確認し、最終的な要約から抜け落ちている可能性のあるプロンプトの変更や前提を把握します。

計画の作成中で、ユーザーから待つように依頼されている場合は、完了するか、作業が阻まれるまで確認を続けます。計画を取得できない場合は、入手できる計画テキストを使って続行し、取得できなかった情報をリスクとして記載します。

整理

各計画から、以下を抽出します。

  • 目的と対象範囲。
  • 重要な前提と未解決の疑問。
  • 提案されているファイル、モジュール、API、データ構造、UI の状態、ワークフロー。
  • 実装の手順。
  • 検証戦略。
  • ロールバックや移行に関する懸念。
  • コスト、複雑さ、想定される実行者との適合性。

冗長さを評価の加点要素にしないでください。具体的で、実際のコードに基づき、トレードオフに誠実な計画を優先します。

相互レビュー

別の有能なエージェントが作成したものとして、各計画をレビューします。

  • ユーザーの実際の依頼を満たしているか確認します。
  • 関連する資料や環境を利用できる場合は、リポジトリ、ドキュメント、テスト、スクリーンショット、外部システムに照らして主張を検証します。
  • 隠れた依存関係、不足しているテスト、リスクの高い手順、曖昧な作業、不要な範囲、元に戻しにくい判断を特定します。
  • 相互補完できる強みを見つけます。一方の計画はアーキテクチャに優れ、もう一方は移行や検証の手順に優れている場合があります。
  • 計画の質と、実行者の選好を分けて考えます。別のモデルが最良の批評をした場合でも、より安価または高速な実行者が実装に適していることがあります。

計画の規模が大きい場合、コードベースが広範囲にわたる場合、または技術面とプロダクト面で個別の検討が有効な場合は、独立したレビューにサブエージェントを使用します。

決定

以下の3つの結果から選びます。

  • 採用: ほぼそのまま、一つの計画を選びます。
  • ハイブリッド: 特定の要素を組み合わせ、より優れた実行計画にします。
  • 先に修正: 両方の計画が重要な制約を見落としている場合や、未解決の判断に依存している場合は、計画の再策定を依頼します。

判断に迷う場合は、次の順で優先します。

  1. 正確性とユーザーの依頼への適合性。
  2. 実際のファイル、API、テスト、データ、UI の動作に基づいていること。
  3. 目指す将来を妨げず、初回の実装がよりシンプルであること。
  4. より優れた検証とロールバックの方針。
  5. 品質が十分な場合、実行にかかるトークンと時間のコストが低いこと。

引き継ぎ

簡潔な意思決定メモを返します。

Decision
- Adopt Plan A / Hybrid / Revise first.

Why
- The deciding evidence and tradeoffs.

Execution Plan
- Ordered steps with files or surfaces to touch.

Borrowed From Other Plans
- Useful pieces kept from non-winning plans.

Rejected
- Ideas intentionally not taking, with reasons.

Verification
- Tests, browser checks, screenshots, CI, review, or deploy checks needed.

Executor Recommendation
- Which agent/model should implement and why.

ユーザーがすでに実行を依頼しており、選択した方針が明確な場合は、判断を簡潔に報告してから、その計画に沿って進めます。それ以外の場合は、引き継ぎの提示で止め、承認を求めます。

コメント