Arena

作者 cursorccb5507cec15無授權條款10K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫今天更新

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

僅含說明AI & Agents
AI 產生的概覽

對同一個任務並行產生多個候選方案,選出最強的一個作為基礎,再把其餘方案的優點移植進去。

功能
Arena 針對同一個任務並行展開 N 個候選嘗試,每個候選產出一份成果物和一段簡短的理由說明。它會依評分標準對候選進行交叉評審,選出一個作為基礎,並手動把落選候選中最強的想法移植進去。最後它會驗證綜合後的結果,產出綜合成果物以及一份簡短的綜合說明,記錄基礎方案、移植內容、被否決的內容、中途失敗的候選以及驗證結果。
適用情境
當對非平凡成果物只做一次嘗試就可能定型成錯誤的樣貌時,或需要在定稿前探索多個設計方向時使用。它由諸如「/arena」「arena this」或「throw it in the arena」之類的請求觸發。
執行需求
僅為指令,不附帶指令碼。它需要能夠產生子代理並在背景執行,以及唯讀的評審子代理;需要為每個候選指定輸出路径,例如 git worktree 或 /tmp 目錄;還需要從規則檔案讀取模型設定,並在該設定缺失時提供了預設模型識別碼。

Arena

Fan out N parallel attempts at the same task. Read every candidate end to end. Pick the strongest as the base. Graft the best ideas from the others into it. Verify the synthesized result.

Start

Open a todolist with one entry per phase before launching anything.

  1. Frame
  2. Fan out
  3. Cross-judge
  4. Pick
  5. Graft
  6. Verify

Phase A: Frame

The N candidates will receive the same prompt, so the prompt is the contract.

  1. State the artifact each candidate is producing.
  2. Derive the rubric. State what success looks like for this task, then turn it into 3-6 concrete gradeable criteria. The rubric is the picker's tool in Phase D. Candidates only see the task.
  3. Pick the runners. Use the arena runners line in ~/.cursor/rules/pstack-models.mdc. If the rule or that line is missing, default to one each on claude-opus-5-5-xhigh and grok-4.7-xhigh-fast. An auto or inherit-parent entry in this line or the cross-judge line means the parent model, so omit model for it. If the Task tool rejects a configured entry, run that seat on its family's default and say so. Families go by prefix: claude-* and grok-*. With no family match, use claude-opus-5-5-xhigh. If it rejects a default, use the closest valid slug of the same family from its error message. Spawn more when the arena covers multiple design directions. Same model N times when the work is generation-bound rather than judgment-sensitive.
  4. Assign output paths. Each candidate writes to its own location (a git worktree where possible, otherwise /tmp/arena-<slug>/candidate-<n>/), per the separate-before-serializing-shared-state principle skill.

Phase B: Fan out

Spawn all N subagents in one message with run_in_background: true, each with the task, the path to the shared grounding, its own output path, and instructions to produce both the artifact and a short rationale.

Each rationale names the alternatives the candidate considered and what it rejected.

If a candidate fails to produce output, proceed with N-1 and note the dropout in the synthesis record.

Phase C: Cross-judge

After all Phase B candidates complete, choose one model from the arena cross-judge pool line in ~/.cursor/rules/pstack-models.mdc. If the rule or that line is missing, choose from claude-opus-5-5-xhigh and grok-4.7-xhigh-fast. Prefer a different model family from the parent's. Spawn one readonly judge subagent on that model. It sees the rubric and the candidates by path label, scores each criterion, and recommends a base with rationale. It runs in parallel with the parent's reading in Phase D, not with the candidates themselves. Don't spawn the judge while candidates are still writing.

Phase D: Pick a base

Read every candidate end to end before picking.

Score each candidate against the rubric criterion by criterion, not on holistic feel. Compare against the cross-judge. Agreement on the base confirms the pick. Disagreement means one of you is biased or the rubric was ambiguous. Read both rationales before deciding.

Pick the base on which candidate a future maintainer can extend most easily without breaking invariants. Prefer the cleaner boundary or smaller API when two feel tied, per the Laziness Protocol.

Record the pick and the reason in a short synthesis note alongside the base artifact, including the cross-judge's verdict.

Phase E: Graft

Walk each losing candidate once more and identify what is worth porting into the base. The signal is usually one or two things per candidate, not most of it.

Fold each graft in by hand, per the redesign-from-first-principles principle skill. Don't paste mechanically. The result has to remain coherent under one mental model.

Record what was grafted, from which candidate, and what was rejected and why.

When N candidates converge on the same shape, that is a strong agreement signal. Note the convergence in the record and ship the consensus shape. No graft is needed. When N candidates wildly diverge, Phase A was under-specified. Reframe and re-run rather than averaging the divergence.

Phase F: Verify

The synthesized artifact has to hold up under the same scrutiny as any other output, per the prove-it-works principle skill.

If verification surfaces a problem the arena did not catch, either Phase A was wrong (re-frame and re-run) or one candidate caught it and you missed the graft (go back to Phase E). Don't paper over.

Outputs

One synthesized artifact. One short synthesis note alongside, naming the base, the grafts (with source candidate), the rejections, the dropouts if any, and the verification result.

來源與署名

來源:cursor/plugins位於pstack/skills/arena提交ccb5507

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架