关于 arena
arena 是用于协调多个候选方案的 Skill，按评分标准比较结果并整合、验证最终产物。它涵盖任务定义、并行执行、评审、选择与合并流程。
主要功能
- 01定义任务与评分标准
- 02并行运行多个候选方案
- 03交叉评审候选结果
- 04依据标准选择方案
- 05整合并验证最终产物
适用场景
- 01比较不同实现方案
- 02评估多个设计提案
- 03整合不同候选方案的优点
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/arena确认已加载。
附带文件agents/openai.yamlCREDITS.md
详细介绍
Arena
粗体列出的原则均位于 principles 技能中：调用一次带有 principles 的 Skill 工具，然后阅读每项列出的原则文件。
在启动任何操作之前，先打开任务列表（使用你的运行环境提供的任务工具；如果没有，则使用 ~/.local/state/ox/checklists/<repo>-<branch>.md 中的检查清单文件），为每个阶段（Frame、Fan out、Cross-judge、Pick、Graft、Verify）各添加一项。
阶段 A：Frame
每个候选方案使用相同的提示词，因此提示词就是约定。
- 说明每个候选方案要产出的产物。
- 推导评分标准，列出 3–6 项具体且可评分的标准，用于衡量这项任务的成功情况。这是阶段 D 中挑选者使用的工具。候选方案只能看到任务。
- 从
~/.config/ox/models.md的panel行选择运行器，每个条目对应一个候选方案，并将每个条目的模型和 effort 传给你的子 Agent 工具。如果文件或该行缺失，或者# harness行指定了不同的运行环境，则使用你自己的模型运行三个候选方案，并说明这一点，同时建议用户运行/setup-ox models：此时候选方案的差异来自采样，而非模型。如果工具拒绝某个条目，则使用它列出的最接近的模型运行该席位，并说明这一点。如果 Arena 涵盖多个设计方向，则增加候选方案。如果任务受生成能力而非判断能力影响，则多次使用同一个模型。 - 为每个候选方案分配独立的输出位置，遵循 Separate Before Serializing Shared State。编写代码的候选方案必须使用独立的 git worktree：先提交基线，因为未提交的编辑不会进入新 worktree；然后运行
git worktree add <path> -b arena-<slug>-<n> <base commit>。其他候选方案则写入各自的目录，即系统临时目录下的arena-<slug>/candidate-<n>/。
阶段 B：Fan out
同时启动全部 N 个候选方案。每份任务说明都应包含任务、共享依据材料的绝对路径、候选方案唯一可写入的专属输出路径，以及产出成果和简短说明的要求；说明中须列出所考虑的替代方案及舍弃理由。等待所有候选方案完成。
在 T3 Code 中，编写代码的候选方案也可以使用 t3_thread_launch 线程，并从基线提交指定 worktree workspaceStrategy，将线程绑定到其 worktree。
如果某个候选方案没有产出任何内容，则继续处理 N-1 个候选方案，并记录该候选方案未完成。
阶段 C：Cross-judge
所有候选方案完成后，启动一个使用 ~/.config/ox/models.md 中 review 行所指定模型的评审者。如果该行指定的模型与你当前运行的模型相同，则使用来自不同模型家族的 panel 条目，避免评审者与你有相同的盲点。如果该行是 inherit 或缺失，则使用你自己的模型运行评审者，并说明这一点。评审者的任务说明应要求其只读：仅进行检查，不得写入或运行 git 命令。它会查看评分标准和以路径标签标识的候选方案，逐项评分，并说明理由、推荐一个基线方案。它会与你在阶段 D 中阅读候选方案的过程并行运行。
阶段 D：Pick a base
挑选之前，完整阅读每个候选方案。按照评分标准逐项评分，而不是凭整体感觉判断，并与交叉评审结果进行比较。对基线方案意见一致，即可确认选择。意见不一致，说明其中一方存在偏见，或评分标准含糊不清。决定前先阅读双方的理由。
选择一个未来维护者最容易扩展、又不会破坏不变量的基线方案。如果两个方案难分高下，则遵循 Laziness Protocol，优先选择边界更清晰或 API 更小的方案。
阶段 E：Graft
再次检查每个落选方案，找出值得移植到基线方案中的内容；通常每个候选方案只移植一两项，而非大部分内容。遵循 Redesign from First Principles，手动整合每项移植内容，确保结果在同一套思路下保持一致。不要机械复制粘贴。
如果各候选方案趋于相同的设计方向，这是强有力的一致信号。记录这一点，并采用共识方案，无需移植内容。如果它们差异悬殊，则说明阶段 A 的任务说明不够明确。应重新定义任务并重新运行，而不是把不同方案折中平均。
阶段 F：验证
按照 证明它有效 的要求，像验证其他输出一样验证综合成果。如果验证发现了竞技场未能发现的问题，要么阶段 A 有误（重新确定框架并重新运行），要么某个候选方案发现了问题，而你漏掉了它的移植（返回阶段 E）。不要敷衍了事。
综合成果合并后，移除每个候选方案的工作树（git worktree remove <path>）和分支。
输出
一个综合成果，以及一份简短的综合说明，注明基础方案及其原因、交叉评审的结论、每项移植及其来源候选方案、被拒绝的内容及原因、任何趋同或退出情况，以及验证结果。