arena

Arena

太字またはバッククォートで示されたスキル名、または /<name> として実行されるスキル名は、このスキルのディレクトリと同じ階層にある ../<name>/SKILL.md ファイルです。プレフィックスなしで示された原則名は、../principle-<name>/SKILL.md ファイルです。そのファイルを読み、内容に従ってください。ほとんどの pstack スキルはユーザー専用なので、スキルツールでは読み込めません。すべての delegate_task 呼び出しには、../poteto-mode/SKILL.md の「Subagents」セクションにあるデフォルト設定が適用されます。

何かを開始する前に、各フェーズ（Frame、Fan out、Cross-judge、Pick、Graft、Verify）につき1項目ずつ、タスクリストを開いてください（お使いのハーネスのタスクツールを使うか、ない場合は ~/.local/state/pstack/checklists/<repo>-<branch>.md にチェックリストファイルを作成してください）。

Phase A: Frame

すべての候補には同じプロンプトを渡すため、プロンプトが契約になります。

1. 各候補が作成する成果物を明示してください。
2. 成功の基準を、このタスクにおいて採点可能な具体的項目として3～6個導き出してください。これはフェーズDで選定者が使う基準です。候補にはタスクだけを提示します。
3. 実行役を選んでください。~/.config/pstack/pstack-models.md の arena runners の行を使い、各エントリーにつき1枠を割り当てます。ファイルまたは該当する行がない場合は、親スレッドのモデルに1枠、さらに orchestrator_capabilities が canRunChildTask を報告する他の各プロバイダーの最強モデルに1枠ずつ、最大3枠を割り当てます。その旨を伝え、/setup-pstack を提案してください。エントリー <providerInstanceId>/<model> (<effort>) は、その枠のプロバイダー、モデル、および orchestrator_capabilities がそのモデル向けに列挙する effort オプション ID を指定します。この行または cross-judge の行に auto または inherit-parent のエントリーがある場合は、親モデルを使います。delegate_task の枠では target 全体を省略し、t3_thread_launch の候補では modelSelection を省略して継承させてください。T3 が設定済みのエントリーを受け付けない場合は、orchestrator_capabilities が列挙する同じプロバイダーの最も近いモデルでその枠を実行し、その旨を伝えてください。複数の設計方針を検討する場合は、実行役を追加してください。判断の精度より生成が中心となる作業では、同じモデルを複数回使ってください。各サブエージェントの推論レベルと高速または標準の速度は、poteto-mode スキルの「Subagents」セクションに従ってタスクに合わせて選んでください。
4. 各候補に独自の出力先を割り当ててください。可能であれば Git worktree を、そうでなければ /tmp/arena-<slug>/candidate-<n>/ を使います。separate-before-serializing-shared-state 原則スキルに従ってください。コードを書く候補には、それぞれ専用の worktree を割り当てます。新しい worktree には未コミットの編集が引き継がれないため、まずベースをコミットしてください。

Phase B: Fan out

N 個すべての候補を1ターンで起動し、それぞれにタスク、共通の根拠資料への絶対パス、個別の出力先を渡します。成果物を作成し、検討した代替案と採用しなかった理由を記した短い根拠も添えるよう指示してください。コードを書く候補は、t3_thread_launch スレッドとして起動し、タイトルを arena <slug>: candidate <n> にします。その際、workspaceStrategy: {"type":"worktree","baseRef":"<base commit>","branch":"arena-<slug>-<n>","startFromOrigin":false}、枠の設定に基づく modelSelection: {"instanceId": ..., "model": ..., "options": ...}、および概要を message に指定してください。t3_thread_wait で完了を待ち、t3_thread_read から worktree のパスを取得してください。それ以外の候補は delegate_task 子タスクとして、mode: "async"、同じタイトル、枠の設定に基づく target、および /tmp の出力先を指定してください。完了通知で処理が再開します。

候補から出力が得られない場合は、N-1 個の候補で進め、離脱した候補について記録してください。

フェーズ C：クロスジャッジ

すべてのフェーズ B の候補が完了したら、~/.config/pstack/pstack-models.md の arena cross-judge pool 行からモデルを 1 つ選びます。ファイルまたはその行が存在しない場合は、orchestrator_capabilities が canRunChildTask に対応すると報告した各プロバイダーの最強モデルから選びます。親とは異なるモデルファミリーを優先します。そのモデルで、mode: "async" の delegate_task 子として、タイトルを arena <slug>: cross-judge に設定したジャッジを 1 つ起動します。ブリーフには、読み取り専用であること、つまり調査のみで、書き込みや git コマンドは行わないことを明記します。ジャッジには、評価基準と絶対パスのラベルが付いた候補を提示し、各評価項目を採点して、根拠とともにベース案を推奨させます。フェーズ D であなたが読み進めている間、ジャッジも並行して実行されます。候補の書き込みが完了する前に起動してはいけません。

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

候補をすべて、選択前に最初から最後まで読みます。全体的な印象ではなく、評価基準の各項目に照らしてそれぞれ採点し、クロスジャッジの結果と比較します。ベース案が一致すれば、その選択は確かなものです。一致しない場合は、どちらかが偏っているか、評価基準が曖昧だったということです。決定する前に、両方の根拠を読みます。

将来のメンテナーが不変条件を壊さずに最も容易に拡張できるベース案を選びます。2 つの案が拮抗している場合は、「Laziness Protocol」に従い、より明確な境界または小さな API を優先します。

フェーズ E：取り込み

各不採用候補をもう一度確認し、ベース案に取り込む価値のある点を探します。通常は候補ごとに 1 つか 2 つであり、大部分を取り込むのではありません。redesign-from-first-principles 原則のスキルに従って、各要素を手作業で統合し、1 つのメンタルモデルのもとで一貫性のある結果にします。機械的に貼り付けてはいけません。

候補が 1 つの形に収束している場合、それは強い合意です。そのことを記録し、合意された形を提出します。取り込みは不要です。候補の内容が大きく食い違っている場合は、フェーズ A の仕様が不十分でした。食い違いを平均化するのではなく、問題を捉え直して再実行します。

フェーズ F：検証

prove-it-works 原則のスキルに従い、ほかの成果物と同様に、統合した成果物を検証します。検証でアリーナが見落とした問題が見つかった場合は、フェーズ A が誤っていた（問題を捉え直して再実行する）か、候補の 1 つが問題を指摘していたのに取り込めなかった（フェーズ E に戻る）かのどちらかです。問題を取り繕ってはいけません。

出力

統合した成果物 1 つと、ベース案とその理由、クロスジャッジの判定、各取り込み要素とその候補元、却下した内容とその理由、収束または離脱の有無、検証結果を記した簡潔な統合メモを併せて出力します。