arena

Arena

以粗体或反引号标出的技能名称，或作为 /<name> 运行的技能，是此技能目录旁边的 ../<name>/SKILL.md 文件；不带前缀的原则名称对应 ../principle-<name>/SKILL.md。读取该文件并遵循其中的说明。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次 delegate_task 调用都遵循 ../poteto-mode/SKILL.md 的 Subagents 部分中的默认设置。

启动任何任务前，先创建任务列表（使用你的工具所提供的任务工具；若没有，则创建清单文件 ~/.local/state/pstack/checklists/<repo>-<branch>.md），每个阶段（Frame、Fan out、Cross-judge、Pick、Graft、Verify）各列一项。

阶段 A：Frame

每位候选者收到相同的提示词，因此提示词就是约定。

1. 说明每位候选者要产出的成果。
2. 制定评分标准：为本任务设定 3–6 项具体、可评分的成功标准，供阶段 D 的挑选者使用。候选者只能看到任务本身。
3. 选择运行器。使用 ~/.config/pstack/pstack-models.md 中的 arena runners 行，每个条目对应一个席位。如果该文件或该行不存在，则默认设置一个席位使用父线程的模型，并为 orchestrator_capabilities 报告 canRunChildTask 的其他各家提供商中最强的模型各设置一个席位，最多三个席位。说明这是默认设置，并建议使用 /setup-pstack。条目 <providerInstanceId>/<model> (<effort>) 会为席位设置提供商、模型，以及 orchestrator_capabilities 为该模型列出的 effort 选项 ID。该行或 cross-judge 行中的 auto 或 inherit-parent 条目表示使用父模型：对于 delegate_task 席位，省略整个 target；对于 t3_thread_launch 候选者，省略 modelSelection，使其继承父模型。如果 T3 拒绝某个已配置条目，则使用 orchestrator_capabilities 列出的同一提供商中最接近的模型运行该席位，并说明此情况。如果 Arena 涵盖多种设计方向，则增加运行器数量。如果任务以生成工作为主，而非对判断力敏感，则多次使用同一模型。根据 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择合适的推理级别以及快速或标准速度。
4. 为每位候选者分配独立的输出位置（尽可能使用 git worktree，否则使用 /tmp/arena-<slug>/candidate-<n>/），遵循 separate-before-serializing-shared-state 原则技能的说明。编写代码的候选者必须使用独立的 worktree。先提交基线，因为未提交的编辑不会传入新的 worktree。

阶段 B：Fan out

在同一轮中启动全部 N 位候选者，每位候选者都提供任务、共享依据的绝对路径、各自的输出路径，并要求他们产出成果及简短说明，指出考虑过哪些替代方案，以及为何舍弃。编写代码的候选者应作为 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 行选择一个模型。如果文件或该行不存在，则从 orchestrator_capabilities 报告支持 canRunChildTask 的每个提供方中，选择其最强的模型。优先选择与父级不同的模型系列。使用该模型，以 delegate_task 子任务的形式启动一位评审，设置 mode: "async"，标题为 arena <slug>: cross-judge，并在任务说明中注明只读：仅检查，不写入，不运行 git 命令。评审会看到评分标准和按绝对路径标注的候选方案，为每项标准打分，并说明理由、推荐一个基础方案。它将在你进行阶段 D 阅读时并行运行。候选方案尚未完成写入时，不要启动评审。

阶段 D：选择基础方案

选择前，通读每个候选方案。按照评分标准逐项评估，而不是凭整体感觉，并与交叉评审的结果进行比较。双方对基础方案意见一致，即可确认选择。若意见不一致，说明你们其中一方存在偏见，或评分标准含糊不清。决定前，先阅读双方的理由。

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

阶段 E：嫁接

再次逐一检查每个落选方案，挑出值得移植到基础方案中的内容，通常每个方案只选一两项，而不是大部分内容。依据 redesign-from-first-principles 原则技能，手动整合每项内容，使结果在统一的思维模型下保持连贯。不要机械粘贴。

如果候选方案趋于同一种形式，这说明各方高度一致。记下这一点，并交付共识方案。无需嫁接。如果候选方案之间差异悬殊，则说明阶段 A 的说明不够明确。重新定义问题并重新运行，而不是折中平均这些差异。

阶段 F：验证

按照 prove-it-works 原则技能，像验证其他输出一样验证综合后的成果。如果验证发现了评审遗漏的问题，要么说明阶段 A 有误（重新定义问题并重新运行），要么说明某个候选方案发现了该问题，而你遗漏了相应的嫁接内容（返回阶段 E）。不要敷衍了事。

输出

一个综合后的成果，并附上一段简短的综合说明，说明基础方案及其选择理由、交叉评审的结论、每项嫁接内容及其来源候选方案、拒绝了哪些内容及原因、是否存在共识或退出情况，以及验证结果。