arena

Arena

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

阶段 A：Frame

每个候选者都会收到相同的提示词，因此提示词就是契约。

1. 说明每个候选者要产出的制品。
2. 拟定评分标准，列出 3-6 项具体且可评分的标准，说明在当前任务中怎样才算成功。这是阶段 D 中挑选者使用的工具。候选者只能看到任务。
3. 选择运行者。使用 ~/.cursor/rules/pstack-models.mdc 中的 arena runners 行。如果规则或该行缺失，则分别在 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast 上运行一个候选者。该行或 cross-judge 行中的 auto 或 inherit-parent 条目表示使用父模型，因此省略 model。如果 Task 工具拒绝已配置的条目，则让该席位使用其所属系列的默认模型，并说明这一点。系列按前缀划分：claude-*，以及 grok-*，后者包括 cursor-grok-* 和 composer-*。被拒绝的 composer-* 条目改用 grok-4.7-xhigh-fast。如果没有匹配的系列，则使用 claude-opus-5-5-xhigh。如果默认模型也被拒绝，则根据错误消息使用同系列中最接近的有效标识符。如果 Arena 涵盖多个设计方向，则增加运行者数量。如果任务受生成能力而非判断能力影响，则重复使用同一模型 N 次。根据 poteto-mode 技能的 Subagents 部分，为工作选择每个子 Agent 的推理级别和快速或标准速度。
4. 为每个候选者指定各自的输出位置（尽可能使用 git worktree，否则使用 /tmp/arena-<slug>/candidate-<n>/），遵循 separate-before-serializing-shared-state 原则技能。

阶段 B：Fan out

在同一条消息中启动全部 N 个子 Agent，并设置 run_in_background: true。每个子 Agent 都要收到任务、共享依据的路径、自身的输出路径，以及产出制品和简短说明的指示；说明需列出它考虑过的替代方案及舍弃原因。

如果某个候选者没有产出，则继续使用 N-1 个候选者，并记录退出情况。

阶段 C：Cross-judge

阶段 B 的所有候选者完成后，从 ~/.cursor/rules/pstack-models.mdc 中的 arena cross-judge pool 行选择一个模型。如果规则或该行缺失，则从 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast 中选择。优先选择与父模型所属系列不同的模型。启动一个只读评审子 Agent。它会查看评分标准和按路径标签标识的候选者，逐项评分并说明理由，推荐一个基础方案。它会与你在阶段 D 的阅读并行运行。候选者仍在写入时，不要启动评审者。

阶段 D：选定基础方案

选定方案前，从头到尾阅读每个候选者。根据评分标准逐项评分，而不是凭整体感觉，并与交叉评审结果进行比较。双方推荐同一个基础方案，即可确认选择。意见不一致则说明你们之中有人存在偏见，或评分标准含糊不清。作出决定前，阅读双方的理由。

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

阶段 E：Graft

对每个落选方案再通读一遍，找出值得移植到基础方案中的内容；通常每个方案取一两点，而不是大部分内容。遵循 redesign-from-first-principles 原则技能，手动融入每项移植内容，使最终结果保持在统一的思维模型下连贯一致。不要机械粘贴。

如果候选方案趋于同一形态，这就是高度一致的信号。记录这一点并交付共识方案，无需移植。如果方案差异很大，说明阶段 A 的要求不够明确。重新梳理并再次运行，而不是将差异取平均。

阶段 F：Verify

遵循 prove-it-works 原则技能，像验证其他输出一样验证综合后的制品。如果验证发现了 Arena 遗漏的问题，则说明阶段 A 有误（重新梳理并再次运行），或者某个候选者发现了问题但你漏掉了对应的移植内容（返回阶段 E）。不要敷衍了事。

输出

一个合成后的产物，并附上一段简短的合成说明，列出基础候选及其原因、交叉评审的结论、每项嫁接及其来源候选、被拒绝的内容及原因、任何趋同或退出情况，以及验证结果。