arena

Arena

太字で示された原則は principles スキルにあります。Skill ツールを使って principles を一度呼び出してから、名前が挙がっている各原則のファイルを読んでください。

何かを開始する前に、タスクリスト（ハーネスのタスクツール、または利用できるものがない場合は ~/.local/state/ox/checklists/<repo>-<branch>.md のチェックリストファイル）を開き、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）につき1項目を設けてください。

Phase A: Frame

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

1. 各候補が作成する成果物を明示します。
2. このタスクでの成功を具体的に評価できる基準を3～6個定め、採点基準を作成します。これは Phase D で選定者が使用するツールです。候補にはタスクのみを見せます。
3. ~/.config/ox/models.md の panel 行から実行モデルを選び、各エントリにつき候補を1つ割り当て、そのエントリのモデルと推論レベルをサブエージェントツールに渡します。ファイルまたはその行が存在しない場合、あるいは # harness 行に別のハーネスが記載されている場合は、自分のモデルで候補を3つ実行し、その旨を伝えて /setup-ox models の実行を提案します。この場合、候補間で異なるのはモデルではなくサンプリングです。ツールがエントリを受け付けない場合は、ツールが提示する中で最も近いモデルをその候補に割り当て、その旨を伝えます。Arena が複数の設計方針を扱う場合は、候補を追加します。作業が判断よりも生成中心の場合は、同じモデルを複数回使用します。
4. Separate Before Serializing Shared State に従い、各候補に専用の出力先を割り当てます。コードを書く候補には、それぞれ専用の git worktree を用意します。まずベースをコミットしてください。未コミットの編集は新しい worktree に引き継がれないためです。その後、git worktree add <path> -b arena-<slug>-<n> <base commit> を実行します。それ以外の候補には、システムの一時ディレクトリ配下にある arena-<slug>/candidate-<n>/ を専用の出力先として割り当てます。

Phase B: Fan out

N 個すべての候補を同時に開始します。各候補への指示には、タスク、共有グラウンディングの絶対パス、その候補だけが書き込み可能な専用出力先、成果物を作成する指示、検討した代替案と却下した案を示す短い根拠を含めます。すべての候補が完了するまで待ちます。

T3 Code では、コードを書く候補の代わりに、ベースコミットからの worktree workspaceStrategy を指定した t3_thread_launch スレッドを使用できます。これにより、スレッドがその worktree に紐付けられます。

候補が何も出力しなかった場合は、N-1 個で続行し、脱落があったことを記録します。

Phase C: Cross-judge

すべての候補が完了したら、~/.config/ox/models.md の review 行にあるモデルで審査役を1つ起動します。その行に現在実行中のモデルが記載されている場合は、審査役に panel の別のモデルファミリーのエントリを使い、同じ盲点を共有しないようにします。その行が inherit または存在しない場合は、自分のモデルで実行し、その旨を伝えます。審査役への指示では、読み取り専用とします。内容の確認のみを行い、書き込みも git コマンドの実行もしないよう指定します。審査役には採点基準と、パスラベルで識別された候補を見せ、各基準を採点したうえで、根拠とともにベースを推奨させます。Phase D であなたが読むのと並行して実行します。

Phase D: ベースを選ぶ

選ぶ前に、すべての候補を最初から最後まで読みます。全体的な印象で決めず、採点基準の各項目に沿ってそれぞれを評価し、クロス審査の結果と比較します。ベースについて意見が一致すれば、その選択が裏付けられます。意見が食い違う場合は、どちらかに偏りがあるか、採点基準が曖昧だったということです。決定する前に、双方の根拠を読みます。

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

Phase E: Graft

選ばなかった候補をもう一度確認し、ベースに取り込む価値のある部分を探します。通常は候補ごとに1～2点で、ほとんどすべてを取り込むわけではありません。Redesign from First Principles に従って、ひとつのメンタルモデルのもとで一貫性を保てるよう、各要素を手作業で統合します。機械的に貼り付けてはいけません。

候補がひとつの形に収束しているなら、それは強い合意を示しています。そのことを記録し、合意された形を採用します。統合作業は不要です。候補が大きく食い違うなら、Phase A での仕様が不十分だったということです。食い違いを平均化するのではなく、問題を定義し直して再実行します。

フェーズ F：検証

動作を証明するに従って、他の出力と同様に統合成果物を検証します。検証でアリーナが見逃した問題が見つかった場合は、フェーズ A が誤っていた（枠組みを見直して再実行する）か、候補のひとつが問題を捉えていたのに統合時に見逃した（フェーズ E に戻る）かのどちらかです。問題を表面上取り繕わないでください。

統合が完了したら、各候補のワークツリー（git worktree remove <path>）とブランチを削除します。

出力

統合成果物を 1 つ作成し、併せて短い統合メモを記載します。メモには、ベースとその理由、クロスジャッジの判定、統合した各変更とその元になった候補、却下した内容とその理由、収束や脱落の有無、検証結果を含めます。