arena

アリーナ

何かを開始する前に、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）ごとに1項目を設けた作業リストを開きます。

Phase A: Frame

候補はすべて同じプロンプトを受け取るため、プロンプトが契約となります。

1. 各候補が作成する成果物を明示します。
2. 成功の基準となる、具体的で採点可能な条件を3～6個定め、評価基準を作成します。主観的な基準については、Eval's criterion and calibration guidance を使用します。これはPhase Dでピッカーが使うツールです。候補にはタスクのみを提示します。
3. 実行役を選びます。arena runners ロールを使用し、各項目に1つのアームを割り当てます。デフォルトでは fable、opus、sonnet がそれぞれ1つずつです。却下された項目にも、以下の必須アームルールが適用されます。アリーナで複数の設計方針を扱う場合は、実行役を追加します。判断への敏感さより生成処理の比重が高い作業では、同じモデルをN回使用します。起動には pstack-harness スキルを使用します。その Spawn a role セクションでロールを解決し、このCLIの起動呼び出しを構築します。
4. 各候補に専用の出力先を割り当てます。可能であればGitワークツリーを使用し、それ以外の場合は、この実行用に新しく作成した mktemp -d "${TMPDIR:-/tmp}/arena-<slug>.XXXXXX" 内の candidate-<n>/ を使用します。これは、separate-before-serializing-shared-state の原則に従います。以前の実行のディレクトリは再利用しないでください。ネイティブの分離オプションが有効なのは、Gitワークツリーを作成し、git -C <its path> rev-parse --path-format=absolute --git-common-dir がプロジェクトのパスを出力する場合に限られます。Grok Build の isolation: worktree は独立したクローンを作成することがあるため、そこで起動する際は isolation: none を指定します。このフィールドを省略すると、Grok のロールまたはペルソナのデフォルトによって分離が有効になる場合があります。残りの候補のワークツリーは、git worktree add --detach <run dir>/candidate-<n> を使って1つずつ自分で作成します。ここで <run dir> は新しく作成した mktemp -d のパスです。候補向けの説明にはパスを記載します。追加に失敗した場合は、すでに作成したワークツリーを削除し、全候補に代わりに通常のディレクトリを用意して、すべての候補が同じ条件で開始できるようにします。通常のディレクトリへの初期データの配置方法と説明方法については、pstack-harness スキルのフォールバックを参照してください。Outputs に従って出力を保存した後、実行が終了した時点で、再フレームと再実行の開始前に作業領域をクリーンアップします。Phase EまたはPhase Fから戻った場合も同様です。クリーンアップするには、各候補のワークツリーを git worktree remove --force <path> で削除し、その候補用に作成したブランチを git branch -D で削除してから、一時ディレクトリを削除します。Phase Eに戻ってGraftを行う場合は、ワークツリーをそのまま保持します。評価基準は、候補が読み取れるすべてのディレクトリの外に置き、クロスジャッジのプロンプトに含めます。

Phase B: Fan out

すべてのN個のサブエージェントを、run_in_background: true を指定して1つのメッセージで起動します。それぞれにタスク、共有グラウンディングのパス、専用の出力パスを渡し、成果物を作成すること、および検討した代替案と却下した理由を挙げた短い根拠を提示するよう指示します。

必須アーム

このタスクで指定されたアームまたは特定のモデルは、引き続き必須です。結果を返せない場合は、有用な出力を保持したうえで、要求された比較が未完了であることを報告します。代替モデルを使用したことと、実際に稼働したモデルを明示します。代替モデルでは、特定モデルの要求を満たしたことにはなりません。設定済みのデフォルトとロールのエイリアスは、通常どおりハーネスで解決されます。デフォルトまたは任意の候補は、制約を記録したうえで脱落してもかまいません。

Phase C: Cross-judge

Phase Bの候補がすべて完了した後、arena cross-judge pool ロールから1つのアームを選びます。解決には pstack-harness スキルの Spawn a role セクションを使用します。デフォルトのプールは fable、opus、sonnet です。親とは異なるモデルファミリーまたは能力層を優先します。そのモデルで、読み取り専用のジャッジサブエージェントを1つ起動します。ジャッジには評価基準と、パスラベルで示された候補を渡し、各基準を採点して、根拠とともにベース案を推奨させます。Phase Dで自分が候補を読む作業と並行して実行します。候補がまだ書き込み中の間は起動しないでください。

フェーズ D：ベースを選ぶ

選ぶ前に、候補ごとの根拠を最初から最後まで読みます。候補の成果物全体を読むのは、それをベースにする場合、または基準について自分とクロスジャッジの見解が異なる場合に限ります。クロスジャッジはすべての成果物を全体にわたって読みます。

全体的な印象ではなく、候補の根拠と、該当する基準についてクロスジャッジが示した証拠に基づいて、各候補を基準ごとに採点します。それらを見ても基準を判断できない場合は、成果物の該当箇所を読みます。クロスジャッジと比較します。ベースについて意見が一致すれば、その選択が確定します。一致や収束を確認する前に、自分、ランナー、クロスジャッジが実行したモデル名を明記してください。同じモデル上で動作した複数の試行は、ひとつの意見にすぎないためです。意見が異なる場合は、どちらかが偏っているか、ルーブリックが曖昧です。判断を下す前に、両方の根拠を読みます。

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

フェーズ E：取り込み

各不採用候補の根拠とクロスジャッジの採点をもう一度確認し、ベースに取り込む価値のある要素を探します。通常、候補ごとに一つか二つであり、大部分を取り込むわけではありません。取り込む部分だけを、不採用候補の成果物から読みます。redesign-from-first-principles 原則スキルに従って、取り込む要素を一つずつ手作業で統合し、単一のメンタルモデルで一貫性を保てるようにします。機械的に貼り付けてはいけません。

候補の形が一つに収束している場合は、フェーズ D で実際に使用したモデルを開示すること、および同一モデルは一つの意見として扱う制約を踏まえたうえで、その収束を記録します。合意された形を採用します。取り込みは不要です。候補が大きく食い違う場合は、フェーズ A の指定が不十分でした。食い違いを平均化するのではなく、問題を再定義して再実行します。再実行の前に、この実行で作成した候補の worktree とブランチを削除し、スクラッチディレクトリも削除します。

フェーズ F：検証

prove-it-works 原則スキルに従い、ほかの出力と同様に、統合した成果物を検証します。検証でアリーナが見落とした問題が見つかった場合は、フェーズ A が誤っていた（問題を再定義して再実行する）か、候補が問題を捉えていたのに取り込みを見落とした（フェーズ E に戻る）かのどちらかです。問題を取り繕ってはいけません。問題を再定義して再実行する前に、この実行で作成した候補の worktree とブランチを削除し、スクラッチディレクトリも削除します。フェーズ E に戻る場合は、それらを保持します。検証に合格したら、出力を保存してから、同じ方法で後片付けをします。

出力

呼び出し元のタスクが指定した場所に保存する、統合済みの成果物を一つ作成します。呼び出し元のタスクが出荷するコードは、作業中のブランチに追加します。呼び出し元の承認を待つスケッチは、タスクが出荷するコードではないため、承認されるまではプロジェクトの外に置きます。保存場所が指定されていないその他の成果物は、プロジェクトの外に新しく作成した mktemp -d に置きます。返信にはファイルではなく、簡潔な統合メモを記載します。そこには、ベースとその選定理由、クロスジャッジの判定、各取り込み要素とその出典候補、却下した要素とその理由、収束や離脱の有無、検証結果を記載します。