arena について
arenaは、候補の並行生成から相互レビュー、選定、統合、検証までを進めるエージェントスキルです。明確な基準で複数案を比較するタスクに適しています。
主な機能
- 01課題設定から検証までの6段階プロセス
- 02タスクに応じた候補評価基準の作成
- 03候補の並行実行と個別出力先の指定
- 04相互レビューと基準ごとの選定
- 05選んだ案への有用な要素の手動統合
活用シーン
- 01同じ課題への複数のアプローチの比較
- 02候補出力から単一の成果物を統合
- 03提出前の生成物の検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/arenaを入力して読み込まれたか確認します。
詳細
Arena
何かを開始する前に、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）につき1項目ずつ、TODOリストを作成します。
フェーズ A：Frame
すべての候補者に同じプロンプトを渡すため、プロンプトが契約となります。
- 各候補者が作成する成果物を明示します。
- 成功の条件を、このタスクに即した具体的で採点可能な基準として3～6個導き出します。これはフェーズ D で選定者が使うツールです。候補者に見せるのはタスクのみです。
- 実行する候補者を選びます。
~/.cursor/rules/pstack-models.mdcのarena runnersの行を使用します。ルールまたはその行がない場合は、claude-opus-5-5-xhighとgrok-4.7-xhigh-fastを1つずつデフォルトとして使用します。この行またはクロスジャッジ用の行にautoまたはinherit-parentの項目がある場合は親モデルを意味するため、その候補者のmodelは省略します。Task ツールが設定された項目を受け付けない場合は、その席でファミリーのデフォルトを実行し、その旨を伝えます。ファミリーはプレフィックスで判定します。claude-*、およびcursor-grok-*とcomposer-*を含むgrok-*が該当します。composer-*が拒否された場合は、grok-4.7-xhigh-fastで実行します。該当するファミリーがない場合は、claude-opus-5-5-xhighを使用します。デフォルトが拒否された場合は、エラーメッセージに記載された同じファミリーの最も近い有効なスラッグを使用します。アリーナが複数の設計方針を対象とする場合は、候補者を追加で起動します。作業が判断の正確さより生成量に左右される場合は、同じモデルを N 回使用します。Subagents セクションの poteto-mode スキルに従い、作業に応じて各サブエージェントの推論レベルと高速または標準の実行速度を選びます。 - separate-before-serializing-shared-state 原則のスキルに従い、各候補者にそれぞれ専用の出力先（可能であれば Git worktree、そうでなければ
/tmp/arena-<slug>/candidate-<n>/）を割り当てます。
フェーズ B：Fan out
1つのメッセージですべての N 個のサブエージェントを起動し、各サブエージェントに run_in_background: true を指定します。それぞれにタスク、共有の根拠資料のパス、専用の出力先を伝え、成果物を作成すること、検討した代替案と却下した案を挙げた短い根拠を示すことを指示します。
候補者が出力を生成しなかった場合は N-1 個で進め、脱落があったことを記録します。
フェーズ C：Cross-judge
フェーズ B のすべての候補者が完了した後、~/.cursor/rules/pstack-models.mdc の arena cross-judge pool の行からモデルを1つ選びます。ルールまたはその行がない場合は、claude-opus-5-5-xhigh と grok-4.7-xhigh-fast から選びます。親モデルとは異なるファミリーを優先します。そのモデルで読み取り専用のジャッジ用サブエージェントを1つ起動します。このサブエージェントには、ルーブリックとパスラベルで示した候補者を見せ、各基準を採点したうえで、根拠とともにベース案を推奨させます。フェーズ D で自分が読み進めるのと並行して実行します。候補者がまだ書き込み中の間は起動しないでください。
フェーズ D：ベース案を選ぶ
選定する前に、すべての候補者を最初から最後まで読みます。全体的な印象ではなく、基準ごとに採点してルーブリックに照らし合わせ、クロスジャッジの結果と比較します。ベース案が一致したら、その選定は妥当です。一致しない場合は、どちらかが偏っているか、ルーブリックが曖昧だったということです。決定する前に、双方の根拠を読みます。
将来のメンテナーが不変条件を壊さずに最も拡張しやすいベース案を選びます。どちらも同程度に思える場合は、Laziness Protocol に従い、境界が明確で API が小さい方を優先します。
フェーズ E：Graft
負けた候補者をもう一度確認し、通常は各候補者から1つか2つ、ベース案に取り入れる価値がある点を探します。大半を移植するのではありません。redesign-from-first-principles 原則のスキルに従って、結果が一貫したメンタルモデルに沿うよう、各要素を手作業で統合します。機械的に貼り付けないでください。
候補者が1つの形に収束した場合は、強い合意があるということです。その旨を記録して、合意された形を採用します。移植は不要です。大きく意見が分かれる場合は、フェーズ A の仕様が不十分でした。意見の平均を取るのではなく、条件を見直して再実行します。
フェーズ F：Verify
prove-it-works 原則のスキルに従い、ほかの出力と同じように合成した成果物を検証します。検証でアリーナが見落とした問題が見つかった場合は、フェーズ A が間違っていた（条件を見直して再実行する）か、候補者が問題に気づいていたのに移植し損ねた（フェーズ E に戻る）かのどちらかです。問題を取り繕わないでください。
出力
1つの統合成果物と、それに添える短い統合メモです。メモには、ベースとその理由、複数の評価者による判定、各取り込み要素とその候補元、却下した内容とその理由、収束または脱落した内容、検証結果を記載します。