arena について
arena は、複数の設計案や成果物を作成・評価し、最終結果にまとめるエージェントスキルです。共通プロンプトとタスク固有の基準を定め、相互評価、選定、統合、検証を経て一貫した成果物を作ります。
主な機能
- 01共通プロンプトでタスクを設定
- 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リストを作成します。
Phase A: Frame
すべての候補に同じプロンプトを渡すため、プロンプトが契約になります。
- 各候補が作成する成果物を明示します。
- このタスクで成功とみなす具体的かつ採点可能な基準を3〜6個導き出し、評価基準を作成します。これはPhase Dで選定者が使うツールです。候補に見せるのはタスクだけです。
- 実行役を選びます。pstack設定ファイル（Cursorでは
~/.cursor/rules/pstack-models.mdc、Claude Codeでは~/.claude/rules/pstack-models.md、その他のハーネスでは~/.agents/pstack-models.md）のarena runners行を使います。ファイルまたはその行がない場合は、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の速度を各サブエージェントに設定します。 - separate-before-serializing-shared-state原則のスキルに従い、各候補に個別の出力先を割り当てます。可能であればgit worktreeを使い、そうでなければ
/tmp/arena-<slug>/candidate-<n>/を使います。
Phase B: Fan out
すべてのN個のサブエージェントを、1つのメッセージでrun_in_background: trueを指定して起動します。それぞれにタスク、共通の根拠資料のパス、個別の出力先を渡し、成果物の作成と、検討した代替案および却下した理由を記した短い説明を指示します。
候補から出力がなかった場合はN-1個で進め、脱落があったことを記録します。
Phase C: Cross-judge
Phase Bの候補がすべて完了した後、pstack設定ファイルのarena cross-judge pool行からモデルを1つ選びます。ファイルまたはその行がない場合は、claude-opus-5-5-xhighとgrok-4.7-xhigh-fastから選びます。親とは異なるモデルファミリーを優先します。そのモデルで読み取り専用の判定サブエージェントを1つ起動します。判定役には評価基準と、パスラベルで示した候補を見せ、各基準を採点したうえで、理由を添えてベースを推奨させます。Phase Dで自分が候補を読むのと並行して実行します。候補がまだ書き込み中の間は起動しません。
Phase D: ベースを選ぶ
選定する前に、すべての候補を最初から最後まで読みます。全体的な印象ではなく、評価基準ごとに採点し、判定役の評価と比較します。ベースの選択が一致すれば、その選択を確定します。不一致の場合は、どちらかが偏っているか、評価基準が曖昧だったことを意味します。判断する前に、双方の説明を読みます。
将来のメンテナーが不変条件を壊さずに最も拡張しやすいベースを選びます。どちらも同等に感じられる場合は、Laziness Protocolに従い、境界が明確でAPIが小さい方を優先します。
Phase E: Graft
採用しなかった候補をもう一度確認し、ベースに取り入れる価値のあるものを探します。通常は各候補から1〜2点であり、大部分を取り込むわけではありません。redesign-from-first-principles原則のスキルに従って、全体が一貫した単一の考え方に沿うよう、各要素を手作業で統合します。機械的に貼り付けてはいけません。
候補が同じ形に収束した場合は、強い一致を示しています。それを記録し、合意された形を採用します。統合は不要です。大きく異なる場合は、Phase Aの仕様が不十分だったということです。相違を平均化するのではなく、要件を定め直して再実行します。
フェーズ F：検証
動作を証明する原則のスキルに従い、ほかの成果物と同様に、統合した成果物を検証します。検証でアリーナが見逃した問題が見つかった場合、フェーズ A が間違っていた（フレーミングをやり直して再実行する）か、候補が問題を捉えていたのに、その内容を取り込めなかった（フェーズ E に戻る）かのどちらかです。問題を取り繕わないでください。
成果物
統合した成果物を 1 つ作成し、併せて、ベースとその選定理由、クロスジャッジの判定、取り込んだ各項目とその候補元、却下した内容とその理由、収束または脱落の有無、検証結果を記した短い統合メモを作成します。