Arena 是 pstack-t3 中的一项技能（skill），可通过 /arena 等触发方式调用。它把同一任务交给多个并行候选方案，从中选出基础版本，再把落选版本中最强的部分移植进来。
用途
Arena 用于同一任务需要多方向探索的场景：让 N 个候选者并行产出同一件交付物，然后选出一个候选作为基础，再把其他候选中最有价值的部分手工并入。其流程分为六个阶段：Frame（定框）、Fan out（并行展开）、Cross-judge（交叉评审）、Pick（选基础）、Graft（移植）、Verify（验证）。
在启动任何工作之前，先建立任务清单（使用你的 harness 的 task 工具，若没有则在 ~/.local/state/pstack/checklists/<repo>-<branch>.md 建一个清单文件），每个阶段一条记录（Frame、Fan out、Cross-judge、Pick、Graft、Verify）。
主要能力
Phase A：Frame（定框）
所有候选者拿到的是同一份 prompt，因此 prompt 就是契约。需要：
- 说明每个候选者要产出的交付物是什么。
- 推导评分标准（rubric），即 3-6 条可具体打分的成功标准。它是 Phase D 中挑选者的工具，候选者只看到任务。
- 选择执行者（runners）。使用 ~/.config/pstack/pstack-models.md 中的 arena runners 行，每个条目对应一个席位。如果该文件或该行缺失，默认在一个席位上使用父线程的模型，并在 orchestrator_capabilities 报告的支持 canRunChildTask 的其他每个 provider 的最强模型上各放一个席位，最多三个席位。要说明这一点并建议 /setup-pstack。条目 <providerInstanceId>/<model> (<effort>) 用于设置该席位的 provider、模型以及 orchestrator_capabilities 为该模型列出的 effort 选项 id。该行或 cross-judge 行中的 auto 或 inherit-parent 条目表示使用父模型：对 delegate_task 席位省略整个 target，对 t3_thread_launch 候选则省略 modelSelection 以使其继承。如果 T3 拒绝某个已配置条目，就在同一个 provider 中 orchestrator_capabilities 列出的最接近模型上运行该席位并说明。当 arena 覆盖多个设计方向时，可以增加执行者；当工作更偏生成而非偏判断时，可以对同一模型重复使用 N 次。按 poteto-mode 技能的 Subagents 一节，为每个子代理挑选推理级别以及快速或标准速度。
给每个候选者自己的输出位置（尽可能用 git worktree，否则用 /tmp/arena-<slug>/candidate-<n>/），遵循 separate-before-serializing-shared-state 原则技能。写代码的候选者要有自己的 worktree。先提交基础版本，因为未提交的改动不会进入新的 worktree。
Phase B：Fan out（并行展开）
在一轮中同时生成全部 N 个候选者，每个都带上任务、共享 grounding 的绝对路径、自己的输出路径，以及产出交付物和简短理由（说明考虑过哪些替代方案、放弃了什么）的指示。写代码的候选者是一个 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 继续并记录掉队情况。
Phase C：Cross-judge（交叉评审）
Phase B 全部候选者完成后，从 ~/.config/pstack/pstack-models.md 中的 arena cross-judge pool 行里选一个模型。如果该文件或该行缺失，就从 orchestrator_capabilities 报告的支持 canRunChildTask 的每个 provider 的最强模型中选。优先选择与父模型不同的模型家族。在该模型上生成一个评审者，作为 delegate_task 子任务，mode: "async"，标题为 arena <slug>: cross-judge，其简述要说明只读：只做检查，不写入，不执行 git 命令。它看到 rubric 以及按绝对路径标签标识的各候选者，逐条为标准打分，并给出推荐基础及理由。它与你在 Phase D 的阅读并行运行。候选者还在写入时不要生成它。
Phase D：Pick a base（选基础）
在挑选之前，端到端读完每一个候选。逐条对照 rubric 打分，而不是凭整体感觉，并与 cross-judge 的结果比较。对基础选择的一致确认此次选择；分歧意味着其中一方有偏差或 rubric 有歧义。决定前要读双方的理由。
选择未来维护者最容易在不破坏不变量前提下扩展的基础。当两个难分高下时，按 Laziness Protocol 优先选择边界更清晰或 API 更小的那个。
Phase E：Graft（移植）
再走一遍每个落选候选，看有什么值得移植进基础，通常每个候选一到两处，而不是大部分。按 redesign-from-first-principles 原则技能，手工把每一处移植并入，使结果在同一个心智模型下保持连贯。不要机械粘贴。
如果各候选收敛到同一种形态，那是强烈的一致，记录下来并交付这一共识形态，无需移植。如果它们差异极大，说明 Phase A 定义不足，应重新定框并重跑，而不是把分歧平均掉。
Phase F：Verify（验证）
按 prove-it-works 原则技能，像验证任何其他产出一样验证合成后的交付物。如果验证发现了 arena 遗漏的问题，要么是 Phase A 错了（重新定框并重跑），要么是某个候选发现了而你漏掉了移植（回到 Phase E）。不要掩盖问题。
输出
一件合成后的交付物，并附一份简短的合成说明，包括：基础是什么及为什么、cross-judge 的裁决、每一处移植及其来源候选、被拒绝的内容及原因、任何收敛或掉队情况，以及验证结果。
使用方式
通过 /arena 等触发方式调用。技能名称若以粗体或反引号标注，或以 /<name> 方式运行，则对应本技能目录旁的 ../<name>/SKILL.md 文件；不带前缀命名的 principle 对应 ../principle-<name>/SKILL.md。读取该文件并遵循它。大多数 pstack 技能是仅用户可用的，因此你的 skill 工具无法加载它们。每次 delegate_task 调用都遵循 ../poteto-mode/SKILL.md 中 Subagents 一节的默认设置。
适用场景与限制
适用于同一任务存在多个合理设计方向、且需要对方案进行结构化比较与合并的场景。它依赖 pstack-t3 的模型配置（~/.config/pstack/pstack-models.md）与 orchestrator_capabilities、t3_thread_launch、delegate_task 等机制；这些配置或能力缺失时会有上述默认回退行为。资料未提供具体收费、价格或性能数据。Arena 本身不定义任务内容，任务定义不清会导致 Phase A 定义不足，需要重新定框并重跑。