arena

Arena

ディスパッチ契約。 ファンアウトの前に、provider-dispatch.md を読んでください。設定値は、ホストネイティブのモデルスラッグではなく、プロバイダーが指定された記述子です。親はネイティブレーンと外部レーンを直接開始します。子が自らルーティングすることはありません。Codex では、残りの Claude ツール名を codex-tools.md で解決してください。

何かを起動する前に、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）ごとに項目を1つずつ設けたToDoリストを開いてください。

Phase A: Frame

すべての候補に同じプロンプトを渡すため、プロンプトが契約になります。

1. 各候補が作成する成果物を明記します。
2. このタスクで成功とみなすための、具体的で採点可能な基準を3～6項目導き出します。これはフェーズDで選定者が使うツールです。候補にはタスクだけを見せます。
3. 実行モデルを選びます。現在のハーネスのpstackモデルシートがある場合は、arena runners を使います。それ以外の場合は、役割ごとのデフォルトを使い、各エントリにつき実行モデルを1つ選びます。アリーナで複数の設計方針を扱う場合は、実行モデルを追加します。判断の鋭さよりも生成量が重視される作業では、同じ記述子をN回使います。poteto-modeスキルのSubagentsセクションに従って、各サブエージェントの作業に適したエフォートを選びます。
4. separate-before-serializing-shared-state原則のスキルに従い、各候補に専用の出力先を割り当てます（可能であればGitのワークツリーを使い、それ以外の場合は /tmp/arena-<slug>/candidate-<n>/ を使います）。

Phase B: Fan out

プロバイダーのディスパッチ契約を通じて、1回のファンアウトフェーズですべてのNレーンを開始します。ネイティブレーンはバックグラウンドのサブエージェントです。外部レーンは、タスク／セッションハンドルを保持するバックグラウンドの直接起動プロセスです。フォアグラウンド呼び出しや、サブプロセスを監督するサブエージェントは使いません。各レーンには、タスク、共通の根拠資料へのパス、専用の出力パスを渡し、成果物と、検討した代替案および却下した理由を記した短い根拠を作成するよう指示します。

外部レーンは、受領記録に complete と記され、対応する provider-report またはCodexの正確な pinned-argv の証拠がある場合にのみ有効とみなします。ネイティブレーンは、ツールのトランスクリプトに割り当てられたモデルの結果が返された場合に有効とみなします。候補が失敗した場合はN-1で進め、脱落の正確な内容を統合記録に記載します。別のプロバイダーで黙って置き換えてはいけません。

Phase C: Cross-judge

フェーズBの候補がすべて完了した後、現在のハーネスのpstackモデルシートに arena cross-judge pool がある場合はそこから、それ以外の場合は上記の実行モデルのデフォルトから、審査モデルの記述子を選びます。親やベース候補となる可能性が高い候補とは異なるプロバイダーを優先します。プロバイダー契約を通じて、読み取り専用の審査役を1つ割り当てます。審査役には、ルーブリックと、パスラベルで識別された候補を見せ、各基準を採点して、根拠とともにベースを推奨させます。フェーズDでの候補の読み込みと並行して実行します。候補の書き込み中に審査役を割り当ててはいけません。

Phase D: Pick a base

選定前に、すべての候補を最後まで読みます。全体的な印象ではなく、基準ごとにルーブリックと照らして採点し、審査役の結果と比較します。ベースの選定が一致すれば、その選択を確定します。一致しない場合は、どちらかに偏りがあるか、ルーブリックが曖昧です。決定する前に、両方の根拠を読みます。

不変条件を壊さずに、将来のメンテナーが最も簡単に拡張できるベースを選びます。どちらも同等に見える場合は、Laziness Protocolに従い、より明確な境界またはより小さなAPIを優先します。

フェーズ E：取り込み

採用しなかった各候補をもう一度確認し、ベースに取り込む価値のある部分を見つけます。通常、候補ごとに取り込むのは 1 つか 2 つで、大半ではありません。redesign-from-first-principles 原則スキルに従い、全体が 1 つのメンタルモデルのもとで一貫性を保つよう、各要素を手作業で取り込みます。機械的に貼り付けないでください。

候補が 1 つの形に収束した場合、それは強い合意です。それを記録し、合意された形をリリースします。取り込みは不要です。大きく食い違う場合は、フェーズ A の仕様が不十分でした。食い違いを平均化するのではなく、問題を再定義して再実行してください。

フェーズ F：検証

他の出力と同様に、prove-it-works 原則スキルに従って、統合した成果物を検証します。検証でアリーナが見逃した問題が見つかった場合は、フェーズ A が誤っていた（問題を再定義して再実行する）か、候補が問題を捉えていたのに取り込みを見逃した（フェーズ E に戻る）かのどちらかです。うやむやにしないでください。

出力

統合した成果物を 1 つと、それに添える短い統合メモを作成します。メモには、ベースとその理由、クロスジャッジの判定、各取り込み要素とその元となった候補、却下した内容とその理由、収束または脱落の有無、検証結果を記載します。