arena

Arena

何かを開始する前に、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）につき1項目を含む ToDo リストを作成します。

フェーズ A：Frame

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

1. 各候補が作成する成果物を明示します。
2. 成功の条件を示す、採点可能で具体的な基準を3～6個導き出します。これはフェーズ D で選定者が使うツールです。候補にはタスクのみを提示します。
3. 実行する候補を選びます。pstack 設定ファイル内の arena runners の行を使用します（Cursor では ~/.cursor/rules/pstack-models.mdc、その他のハーネスでは ~/.agents/pstack-models.md）。ファイルまたはその行がない場合は、claude-opus-5-5-xhigh と grok-4.7-xhigh-fast をそれぞれ1つずつ使用します。この行または cross-judge の行に auto または inherit-parent が指定されている場合は親モデルを使うため、model を省略します。サブエージェントツールが設定されたエントリを受け付けない場合は、その枠を同じファミリーのデフォルトモデルで実行し、その旨を伝えます。ファミリーはプレフィックスで判断します。claude-*、および cursor-grok-* と composer-* を含む grok-* が該当します。composer-* が拒否された場合は、grok-4.7-xhigh-fast で実行します。該当するファミリーがない場合は、claude-opus-5-5-xhigh を使用します。デフォルトモデルが拒否された場合は、エラーメッセージまたはハーネスのモデル一覧から、同じファミリーの中で最も近い有効なスラッグを使用します。Arena が複数の設計方針を対象とする場合は、候補を増やします。作業が判断より生成に重点を置く場合は、同じモデルを N 回使用します。poteto-mode スキルの Subagents セクションに従い、タスクに応じて各サブエージェントの推論レベルと fast または standard の速度を選びます。
4. separate-before-serializing-shared-state 原則スキルに従い、各候補にそれぞれ専用の出力場所を割り当てます。可能であれば git worktree を使用し、そうでなければ /tmp/arena-<slug>/candidate-<n>/ を使用します。

フェーズ B：Fan out

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

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

フェーズ C：Cross-judge

フェーズ B のすべての候補が完了したら、pstack 設定ファイルの arena cross-judge pool の行からモデルを1つ選びます。ファイルまたはその行がない場合は、claude-opus-5-5-xhigh と grok-4.7-xhigh-fast から選びます。親モデルとは異なるファミリーのモデルを優先します。そのモデルで、読み取り専用の判定サブエージェントを1つ起動します。判定サブエージェントにはルーブリックと、パスラベルで示した候補を提示し、各基準を採点して、根拠とともにベース候補を推薦させます。フェーズ D で自分が候補を読むのと並行して実行します。候補の書き込み中は起動しないでください。

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

すべての候補を最初から最後まで読んでから選びます。総合的な印象ではなく、ルーブリックの各基準に沿って採点し、cross-judge の評価と比較します。ベース候補について意見が一致すれば、その選定を確認できます。意見が分かれた場合は、どちらかに偏りがあるか、ルーブリックが曖昧だったことを意味します。決定する前に、両方の根拠を読みます。

不変条件を壊さずに将来のメンテナーが最も拡張しやすいベースを選びます。優劣がつかない場合は、Laziness Protocol に従い、より明確な境界または小さな API を優先します。

フェーズ E：Graft

ベースに取り入れる価値のある点を探すため、採用しない候補をそれぞれもう一度確認します。通常は、候補ごとに1つか2つ程度です。redesign-from-first-principles 原則スキルに従い、機械的に貼り付けるのではなく、手作業で統合して、1つのメンタルモデルのもとで一貫性を保ちます。

候補が1つの形に収束している場合は、強い合意とみなします。そのことを記録し、合意された形を採用します。統合は不要です。候補が大きく食い違う場合は、フェーズ A の仕様が不十分です。食い違いを平均化するのではなく、要件を整理し直して再実行します。

フェーズ F：検証

動作を証明する原則のスキルに従い、ほかの成果物と同様に、統合した成果物を検証します。検証でアリーナが見逃した問題が見つかった場合、フェーズ A が間違っていた（フレーミングをやり直して再実行する）か、候補が問題を捉えていたのに、その内容を取り込めなかった（フェーズ E に戻る）かのどちらかです。問題を取り繕わないでください。

成果物

統合した成果物を 1 つ作成し、併せて、ベースとその選定理由、クロスジャッジの判定、取り込んだ各項目とその候補元、却下した内容とその理由、収束または脱落の有無、検証結果を記した短い統合メモを作成します。