用途：对同一任务并发生成 N 个候选方案，逐个阅读后选出最强的一个作为基线，把落选者中最好的想法移植进去，再对合成结果做验证。适用于“/arena”“arena this”这类触发方式。
主要能力与流程：启动前先建立待办清单，每个阶段一条。阶段 A 定框：所有候选者接收同一提示词，因此提示词即契约；说明每个候选者要产出的产物；按任务推导评分标准（3-6 条可评分的具体准则，候选者只看任务，评分标准供选者使用）；选择执行者、分配输出路径（尽可能用 git worktree，否则用 /tmp/arena-<slug>/candidate-<n>/，一个工作树只允许一个写入者）。阶段 B 并发：用 delegate_task 在同一轮启动全部候选者，每条执行者一条，模式为 async；子代理只拿到简报，简报需自包含（任务、共享背景路径、各自输出路径、产出产物与简短理由），理由要说明考虑过并否决了哪些替代方案；用 task_status 收拢，若某候选者无输出则以 N-1 继续并记录掉队。阶段 C 交叉评判：候选者全部完成后，从交叉评判池选一个模型（尽量与父模型不同供应商）启动只读评判者，它按评分标准逐项打分并推荐基线与理由，与阶段 D 的父级阅读并行，但不得在候选者仍在写入时启动。阶段 D 选基线：将每个候选者按评分标准逐项打分，而非整体感觉；与交叉评判结果对照，一致则确认，分歧则需读双方理由再决定；倾向于未来维护者更易扩展、边界更清晰或 API 更小的方案，并把选择与理由连同评判结论记入简短合成记录。阶段 E 移植：逐一回看落选者，通常每个只值得移植一两点；手工融入而非机械粘贴，结果须在同一心智模型下保持一致；记录移植内容、来源与被否决项及原因。若多候选者收敛到同一形态属强一致信号，可直接采用共识形态；若严重分歧说明阶段 A 定义不足，应重新定框重跑而非取平均。阶段 F 验证：合成产物须通过与其他输出相同的检验；若验证暴露 arena 未发现的问题，或是阶段 A 有误（重新定框重跑），或是某候选者已发现但漏了移植（回到阶段 E），不得掩盖。
前置与限制：在解析模型或委派之前需先阅读 T3 执行说明，它定义全局配置、容量选择与传输约束，其顶层会话要求适用于所有启动，否则应使用受支持的子隔离或报告运行时限制。若 pstack-models.md 文件或角色缺失，使用该角色内置默认值；该行或交叉评判行中的 auto 或 inherit-parent 表示父模型，此时省略 model；容量选定的席位不可用时通过执行参考解析其他合适账户或模型；替换固定或用户选定模型前需先询问。具体命令与参数以资料所载为准，未提供的细节暂未提供。