arena

竞技场

在 Codex 上，遵循此技能之前，请阅读平台映射，包括其中针对各项技能的说明。

在 GitHub Copilot 上，遵循此技能之前，请阅读平台映射，包括其中针对各项技能的说明。

在 Muse 上，遵循此技能之前，请阅读平台映射，包括其中针对各项技能的说明。

启动任何操作之前，先创建一份待办清单，每个阶段（Frame、Fan out、Cross-judge、Pick、Graft、Verify）各列一项。

阶段 A：Frame

所有候选方案都会收到相同的提示词，因此提示词就是约定。

1. 说明每个候选方案要产出的制品。
2. 推导评分标准，列出 3-6 项具体、可评分的标准，明确这项任务的成功表现。它将作为阶段 D 中挑选方案的工具。候选方案只能看到任务本身。
3. 选择运行器。使用 pstack-models.md 中的 arena runners 行。如果找不到该表或该行，就按模型中的默认项各运行一个。如果该行或交叉评审行中有 auto 或 inherit-parent 条目，表示使用父模型，因此省略 model。如果 Agent 工具拒绝已配置的条目，就让该席位使用其所属系列的默认项运行，并说明此情况。系列按模型名称划分，例如 Opus、Fable 或 Sonnet。如果没有匹配的系列，则使用模型中的单角色默认项。如果默认项被拒绝，则根据错误消息，使用同一系列中最接近的有效 slug。如果竞技场涵盖多个设计方向，就增加运行器。对于生成主导而非判断敏感的工作，可重复使用同一个模型 N 次。按照 poteto-mode 技能的 Subagents 部分，根据任务选择每个子 Agent 的推理级别。
4. 按照 separate-before-serializing-shared-state 原则技能，为每个候选方案指定独立的输出位置（尽可能使用 git worktree，否则使用 /tmp/arena-<slug>/candidate-<n>/）。

阶段 B：Fan out

在一条消息中启动全部 N 个子 Agent，并设置 run_in_background: true。每个子 Agent 都要收到任务、共享依据的路径、各自的输出路径，以及产出制品并简要说明理由的指示，其中要列出它考虑过的备选方案及舍弃理由。

如果某个候选方案没有产出，就按 N-1 个候选方案继续，并记录该候选方案未能产出。

阶段 C：Cross-judge

阶段 B 的所有候选方案完成后，从 pstack-models.md 中的 arena cross-judge pool 行选择一个模型。如果找不到该表或该行，就从模型中的运行器默认项中选择。优先选择与父模型所属系列不同的模型。使用该模型启动一个只读评审子 Agent。它会看到评分标准，以及按路径标签标注的候选方案，对每项标准分别打分，并说明理由、推荐一个基础方案。它会与您在阶段 D 的阅读工作并行运行。候选方案尚未完成写入时，不要启动它。

阶段 D：挑选基础方案

挑选之前，逐一完整阅读所有候选方案。逐项按照评分标准评分，而不是凭整体印象，并与交叉评审结果比较。对基础方案的意见一致，即可确认选择。意见不一致意味着你们其中一方存在偏见，或者评分标准含糊不清。做决定之前，阅读双方的理由。

选择最方便未来维护者扩展、又不会破坏不变量的基础方案。如果两个方案难分高下，按照 Laziness Protocol，优先选择边界更清晰或 API 更小的方案。

阶段 E：Graft

再逐一检查每个落选方案，找出值得移植到基础方案中的内容；通常每个方案移植一两点，而不是大部分内容。按照 redesign-from-first-principles 原则技能，手动整合每项移植内容，确保最终结果在同一套思维模型下保持连贯。不要机械粘贴。

如果各候选方案趋于同一种结构，这就表明它们高度一致。记录这一点，并交付共识方案，无需移植内容。如果它们差异巨大，说明阶段 A 的说明不够明确。应重新制定框架并再次运行，而不是折中处理这些差异。

阶段 F：验证

按照 prove-it-works 原则技能，像验证其他输出一样验证合成产物。如果验证发现了竞技场遗漏的问题，那么要么是阶段 A 有误（重新构建框架并重新运行），要么是某个候选版本发现了问题，而你漏掉了移植（返回阶段 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 派发则沿用会话的推理力度。