arena

アリーナ

Codex では、このスキルに従う前に、スキルごとの注記も含めてプラットフォームマッピングを読んでください。

GitHub Copilot では、このスキルに従う前に、スキルごとの注記も含めてプラットフォームマッピングを読んでください。

Muse では、このスキルに従う前に、スキルごとの注記も含めてプラットフォームマッピングを読んでください。

何かを起動する前に、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）につき1項目ずつ、ToDoリストを開いてください。

Phase A: Frame

すべての候補に同じプロンプトを渡します。プロンプトが契約です。

1. 各候補が作成する成果物を明示します。
2. このタスクで成功とみなす条件を、採点可能な具体的基準3〜6個にまとめて評価基準を作成します。これはフェーズDで選定者が使うツールです。候補にはタスクだけを見せます。
3. 実行役を選びます。pstack-models.md の arena runners 行を使います。シートまたはその行がない場合は、Modelsのデフォルトからそれぞれ1つ実行します。この行またはクロスジャッジの行に auto または inherit-parent の指定がある場合は、親モデルを意味するため、model は省略します。Agent ツールが設定済みの指定を受け付けない場合は、その担当をファミリーのデフォルトで実行し、その旨を伝えます。ファミリーは、Opus、Fable、Sonnet など、モデル名で判断します。ファミリーに該当するものがない場合は、Modelsの単一ロール用デフォルトを使います。デフォルトが受け付けられない場合は、エラーメッセージにある同じファミリーの、最も近い有効なスラッグを使います。アリーナが複数の設計方針を扱う場合は、実行役を増やします。作業が判断よりも生成に左右される場合は、同じモデルをN回使います。poteto-mode スキルのSubagentsセクションに従い、各サブエージェントの推論レベルを作業に合わせて選びます。
4. separate-before-serializing-shared-state 原則スキルに従い、各候補に専用の出力先を用意します（可能ならGitワークツリー、そうでなければ /tmp/arena-<slug>/candidate-<n>/）。

Phase B: Fan out

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

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

Phase C: Cross-judge

フェーズBの候補がすべて完了した後、pstack-models.md の arena cross-judge pool 行からモデルを1つ選びます。シートまたはその行がない場合は、Modelsの実行役デフォルトから選びます。親とは異なるモデルファミリーを優先します。そのモデルで、読み取り専用の判定サブエージェントを1つ起動します。サブエージェントには評価基準と、パスのラベルで示した候補を見せ、各基準を採点して、根拠とともにベース案を推奨させます。フェーズDで自分が候補を読むのと並行して実行します。候補の書き込みがまだ完了していない間は起動しないでください。

Phase D: Pick a base

選ぶ前に、すべての候補を最初から最後まで読みます。全体的な印象ではなく、各評価基準に沿ってそれぞれを採点し、クロスジャッジの結果と比較します。ベース案の一致は、選定が妥当であることを裏付けます。不一致の場合は、どちらかに偏りがあるか、評価基準が曖昧だったことを意味します。決める前に、両方の根拠を読みます。

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

Phase E: Graft

各不採用候補をもう一度確認し、ベース案に取り込む価値があるものを探します。通常、候補ごとに1つか2つであり、大部分を取り込むわけではありません。redesign-from-first-principles 原則スキルに従い、1つのメンタルモデルで一貫性を保てるよう、手作業でそれぞれを取り込みます。機械的に貼り付けないでください。

候補が同じ形に収束している場合は、強い合意を示しています。そのことを記録し、合意された形を採用します。取り込みは不要です。候補が大きく分かれている場合は、フェーズAの仕様が不十分でした。違いを平均化するのではなく、改めて定義して再実行します。

Phase F：検証

prove-it-works 原則スキルに従い、他の出力と同様に、統合した成果物を検証します。検証でアリーナが見落とした問題が見つかった場合は、Phase A が誤っていた（枠組みを見直して再実行する）か、候補の一つが問題を捉えていたのに、その取り込みを見落とした（Phase E に戻る）かのどちらかです。問題を取り繕わないでください。

出力

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

モデル

plugins/pstack/models.json に記載されている役割ごとのデフォルト値（編集後、tools/generate.mjs を再実行します）。pstack-models.md オーバーライドシートに同じ役割の行がある場合、実行時にはその値が各デフォルト値を上書きします。/setup-pstack はこのシートを書き込み、ランタイムごとにそのパスを一覧表示します。

• アリーナ実行役：opus、fable、sonnet、haiku
• アリーナのクロスジャッジ候補：opus、fable、sonnet、haiku

推論の強度

オーバーライドシートの役割の値には、モデル名の後に推論の強度を指定できます（例：opus @xhigh）。Claude Code で指定できるレベルは、low、medium、high、xhigh、max です。どのレベルを使えるかはモデルによって異なります。@ のない値には、シートの default effort 行に指定されたレベルまたは session が適用されます。その行がない場合は session が適用されます。session は推論の強度を設定しないため、通常どおりディスパッチされます。モデル名を読み取る前に、接尾辞を取り除いてください。inherit-parent または auto の場合は、どのレベルでも model が省略され、モデル名の場合は model として渡されます。レベルはディスパッチの推論強度フィールドに渡し、それ以外は通常使用する subagent_type をそのまま使用してください。これは、Claude Code の Agent 呼び出しでは effort、Codex の spawn_agent では reasoning_effort にあたります。Muse では、Workflow 子要素の effort にあたります。subagent_spawn ディスパッチでは、セッションの推論強度が引き継がれます。