arena

アリーナ

同じタスクに対して N 個の試行を並行して行います。候補を最初から最後まで読みます。最も優れた候補をベースとして選び、ほかの候補から優れたアイデアを取り入れます。統合した結果を検証します。

開始

何かを実行する前に、各フェーズを 1 項目ずつ記載した TODO リストを作成します。

1. 枠組みを決める
2. 試行を並行して進める
3. 相互評価する
4. 選ぶ
5. 取り入れる
6. 検証する

フェーズ A：枠組みを決める

N 個の候補には同じプロンプトが渡されるため、プロンプトが契約になります。

1. 各候補が作成する成果物を明示します。
2. 評価基準を導き出します。このタスクにおける成功の条件を示し、採点可能な具体的基準を 3～6 個にまとめます。評価基準はフェーズ D で選ぶ際のツールになります。候補にはタスクのみを提示します。
3. 実行するモデルを選びます。~/.cursor/rules/pstack-models.mdc の arena runners 行を使用します。このルールまたは該当行がない場合は、claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast を各 1 つ使用します。この行または相互評価行の auto または inherit-parent は親モデルを意味するため、その場合は model を省略します。Task ツールが設定済みの項目を受け付けない場合、その枠では同じファミリーのデフォルトモデルを使用し、その旨を伝えます。ファミリーは接頭辞で判定します：claude-*、gpt-*、grok-*。該当するファミリーがない場合は claude-opus-5-5-max を使用します。デフォルトモデルも受け付けられない場合は、エラーメッセージに示された同じファミリーの有効なスラッグのうち、最も近いものを使用します。アリーナが複数の設計方針を扱う場合は、さらにモデルを起動します。作業が判断よりも生成に左右される場合は、同じモデルを N 回使用します。
4. 出力先のパスを割り当てます。共有状態のシリアライズ前に分離するという原則に従い、各候補がそれぞれの場所（可能であれば Git ワークツリー、そうでなければ /tmp/arena-<slug>/candidate-<n>/）に出力します。

フェーズ B：試行を並行して進める

1 回のメッセージで N 個すべてのサブエージェントを run_in_background: true で起動します。各エージェントには、タスク、共有の根拠資料へのパス、固有の出力先を渡し、成果物と短い根拠説明の両方を作成するよう指示します。

各根拠説明には、候補が検討した選択肢と、採用しなかったものを記載します。

候補が出力を作成できなかった場合は、N-1 個で続行し、統合記録に脱落を記載します。

フェーズ C：相互評価する

フェーズ B の候補がすべて完了したら、~/.cursor/rules/pstack-models.mdc の arena cross-judge pool 行からモデルを 1 つ選びます。このルールまたは該当行がない場合は、claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast から選びます。親モデルとは異なるファミリーを優先します。そのモデルで読み取り専用の評価サブエージェントを 1 つ起動します。評価者には評価基準と、パスラベルで識別した候補を渡し、各基準を採点したうえで、根拠とともにベース候補を推薦させます。評価者は親がフェーズ D で読むのと並行して動作させます。候補の作成中に評価者を起動してはいけません。

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

すべての候補を最初から最後まで読んでから選びます。

各候補を全体的な印象で判断するのではなく、評価基準ごとに採点します。クロス評価の結果と比較します。ベースの選択が一致すれば、その選択を確認できます。一致しない場合は、どちらかに偏りがあるか、評価基準が曖昧です。決定する前に、両方の根拠説明を読みます。

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

ベースの成果物とともに短い統合メモを記録し、選択した候補とその理由、およびクロス評価者の判定を記載します。

フェーズ E：取り込み

敗れた候補をもう一度ひとつずつ確認し、ベースに取り込む価値があるものを特定します。通常、各候補から得られる有用な要素は1つか2つで、大部分ではありません。

redesign-from-first-principles原則スキルに従い、取り込む要素をひとつずつ手作業で統合します。機械的に貼り付けてはいけません。結果は、ひとつのメンタルモデルのもとで一貫性を保つ必要があります。

何を、どの候補から取り込んだのか、何を却下したのか、そしてその理由を記録します。

N個の候補が同じ形に収束した場合、それは強い一致の兆候です。記録にその収束を記し、合意された形を採用します。取り込みは不要です。N個の候補が大きく分かれた場合、フェーズAの仕様が不十分でした。分岐の平均を取るのではなく、枠組みを見直して再実行します。

フェーズ F：検証

統合した成果物は、prove-it-works原則スキルに従い、ほかの出力と同じ厳しい検証に耐える必要があります。

検証でアリーナが見逃した問題が見つかった場合は、フェーズAが誤っていた（枠組みを見直して再実行する）か、候補のひとつが問題を捉えていたのに、その要素を取り込み損ねた（フェーズEに戻る）かのどちらかです。問題を取り繕ってはいけません。

成果物

統合した成果物をひとつ。そのほかに、ベース、取り込んだ要素（元の候補を含む）、却下した要素、脱落した候補があればその内容、検証結果を記した短い統合メモを添えます。