关于 arena
arena 是用于生成和评估多个候选设计或产物的 Agent 技能，随后综合形成结果。它先制定统一提示词和任务专属标准，再通过交叉评审、选定基础方案、整合与验证产出一致成果。
主要功能
- 01用统一提示词界定任务
- 02制定可评分的评估标准
- 03在独立位置运行候选方案
- 04交叉评审并选定基础方案
- 05整合有用构想并验证
适用场景
- 01实现前比较不同设计方案
- 02将多个草稿综合为单一产物
- 03依据明确标准评估候选结果
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/arena确认已加载。
详细介绍
竞技场
在启动任何操作之前，先打开一个待办清单，为每个阶段各添加一项（Frame、Fan out、Cross-judge、Pick、Graft、Verify）。
阶段 A：Frame
每个候选方案收到的提示词都相同，因此提示词就是约定。
- 说明每个候选方案要产出的成果。
- 制定评分标准，列出 3-6 项具体、可评分的标准，明确本任务的成功标准。这是阶段 D 中挑选者使用的工具。候选方案只能看到任务。
- 选择运行器。使用 pstack 设置文件中的
arena runners行（Cursor 中为~/.cursor/rules/pstack-models.mdc，Claude Code 中为~/.claude/rules/pstack-models.md，其他运行环境中为~/.agents/pstack-models.md）。如果文件或该行缺失，则默认分别使用一个claude-opus-5-5-xhigh和一个grok-4.7-xhigh-fast。如果此行或 cross-judge 行中的条目为auto或inherit-parent，则表示使用父模型，因此省略model。如果你的子 Agent 工具拒绝某个已配置的条目，则让该席位使用其所属系列的默认模型，并说明这一点。系列按前缀划分：claude-*，以及grok-*（包含cursor-grok-*和composer-*）。被拒绝的composer-*条目使用grok-4.7-xhigh-fast运行。若没有匹配的系列，则使用claude-opus-5-5-xhigh。如果默认模型也被拒绝，则根据错误消息或运行环境的模型列表，使用同一系列中最接近的有效 slug。若竞技场涵盖多个设计方向，则增加运行器数量。如果任务受生成能力而非判断敏感度影响，则重复使用同一模型 N 次。根据 poteto-mode 技能中的 Subagents 部分，为任务选择每个子 Agent 的推理级别以及 fast 或 standard 速度。 - 为每个候选方案指定各自的输出位置（尽可能使用 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 的所有候选方案完成后，从 pstack 设置文件的 arena cross-judge pool 行中选择一个模型。如果文件或该行缺失，则从 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast 中选择。优先选择与父模型不同系列的模型。使用该模型启动一个只读评审子 Agent。它会看到评分标准和按路径标签标记的候选方案，逐项评分并说明理由，推荐一个基础方案。评审子 Agent 会与你在阶段 D 阅读候选方案的工作并行运行。候选方案尚在编写时，不要启动它。
阶段 D：选择基础方案
在作出选择前，从头到尾阅读每个候选方案。按照评分标准逐项评分，而非凭整体感觉判断，并与 cross-judge 的评审结果对比。若双方对基础方案达成一致，即可确认选择。若意见不一致，则说明你们其中一方存在偏见，或评分标准不够明确。作出决定前，阅读双方的理由。
选择最便于未来维护者扩展、且不破坏不变量的基础方案。若两个方案难分高下，则根据 Laziness Protocol，优先选择边界更清晰或 API 更小的方案。
阶段 E：Graft
再次检查每个落选方案，看看有哪些内容值得移植到基础方案中；通常每个方案挑选一两项，而非大部分内容。按照 redesign-from-first-principles 原则技能，手动整合每项移植内容，确保最终结果遵循统一的思维模型，保持连贯。不要机械粘贴。
如果候选方案都趋于同一种形式，说明各方高度一致。请注明这一点，并交付共识方案。无需移植任何内容。如果候选方案大相径庭，说明阶段 A 的描述不够明确。应重新界定任务并重新运行，而不是折中拼凑。
阶段 F：验证
按照 prove-it-works 原则技能的要求，像验证其他输出一样验证综合产物。如果验证发现了评审环节遗漏的问题，那么要么是阶段 A 出错了（重新界定问题并重新运行），要么是某个候选方案发现了问题，而你漏掉了合并的改进（返回阶段 E）。不要掩盖问题。
输出
一个综合产物，并附上一条简短的综合说明，说明所选基准及其原因、交叉评审的结论、每项合并改进及其来源候选方案、被拒绝的内容及原因、任何收敛或退出情况，以及验证结果。