cross-critique

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Cross-Critique

交叉评审(Cross-Critique)

Use this skill to run a second round after several subagents have independently produced proposals or opinions on the same contested question. Instead of synthesizing their reports yourself, you circulate each proposal to the other authors and ask them to critique it — pros and cons — and then you synthesize the richer set of analyses that results.
当多个子代理(subagent)针对同一争议性问题独立产出方案或意见后,可使用该技能开展第二轮评审。无需你自行综合这些报告,而是将每个方案传阅给其他作者,让他们对方案进行优缺点评审,之后你再基于更丰富的分析结果进行综合。

Why this matters

为何这很重要

When you generate independent proposals (different models, different angles), each author ends up with deep context on the question — often deeper than yours, since they did the investigation. If you jump straight to synthesizing their reports alone, you're the bottleneck: you can only see the tradeoffs you happen to notice.
Asking the authors to critique each other is what a good leader does when seeking advice: get a few people with differing perspectives in a room, let them poke holes in each other's reasoning, and you walk away with a far more complete picture than any one of them — or you — would produce alone. The authors will surface failure modes, hidden assumptions, and tradeoffs that neither you nor the original proposer flagged.
当你生成独立方案(不同模型、不同视角)时,每个作者都会对问题有深入的背景了解——通常比你更深入,因为他们完成了调研工作。如果直接自行综合这些报告,你就会成为瓶颈:你只能发现自己碰巧注意到的权衡点。
让作者互相评审,就像优秀领导者寻求建议时的做法:让几位持不同观点的人一起讨论,让他们指出彼此推理中的漏洞,最终你得到的信息会比任何一位作者或你单独分析的结果更全面。作者们会发现你和原提案者都未注意到的失效模式、隐藏假设和权衡点。

When to use it

使用场景

Use cross-critique when a decision is contested — i.e. independent agents produced genuinely divergent proposals, or the question is subjective enough that reasonable approaches disagree. Good fits:
  • Architecture and design tradeoffs.
  • Code review where reviewers reached different conclusions.
  • Competing root-cause theories for a bug.
  • Code-structure or API-shape decisions with no single right answer.
Don't bother when the proposals already strongly agree, or when the question has an objective answer you can verify directly — critique adds latency and tokens, and its value comes specifically from resolving genuine disagreement. Within that scope, use it freely; you don't need a high-stakes justification, just real divergence worth resolving.
当决策存在争议时使用交叉评审——即独立代理产出了真正不同的方案,或者问题主观性较强,合理的解决方案存在分歧。适用场景包括:
  • 架构与设计权衡
  • 评审结论存在分歧的代码评审
  • 针对Bug的相互竞争的根本原因理论
  • 没有唯一正确答案的代码结构或API形态决策
如果方案已高度一致,或者问题有可直接验证的客观答案,则无需使用该技能——评审会增加延迟和token消耗,其价值仅在于解决真正的分歧。在适用范围内可自由使用,无需高风险理由,只要存在值得解决的真实分歧即可。

Prerequisite: you need independent proposals first

前提:需先获得独立方案

This skill is the second round. It assumes you already have N independent proposals in hand. If you don't yet:
  • For a judgment-heavy decision, generate them with the council skill (model-diverse subagents on the same question).
  • For an investigation-heavy question, generate them by spawning parallel subagents (see the research skill).
  • Or use any ad-hoc set of independent subagent proposals you've already collected.
Critically, the first round must be independent — do not let the authors see each other's work during round one, or you lose the diversity that makes round two valuable.
该技能是第二轮流程,假设你已拥有N个独立方案。如果还没有:
  • 对于侧重判断的决策,使用council技能生成方案(针对同一问题的多模型子代理)
  • 对于侧重调研的决策,通过生成并行子代理来获取方案(参考research技能)
  • 或者使用你已收集的任意一组独立子代理方案
关键在于,第一轮必须是独立的——不要让作者在第一轮看到彼此的成果,否则会失去让第二轮有价值的多样性。

How to do it

操作步骤

1. Assemble the proposals

1. 整理方案

Collect each author's proposal. Keep them concise — the core recommendation and its reasoning, not the full transcript. Consider labeling them neutrally (Proposal A, B, C) and, where practical, anonymizing authorship to reduce bandwagon bias toward whichever model sounds most confident.
收集每位作者的方案,保持简洁——核心建议及其理由,而非完整记录。考虑用中性标签(方案A、B、C)标注,如有可能,匿名作者身份以减少对看似更自信模型的从众偏见。

2. Circulate and ask for structured critique

2. 传阅并要求结构化评审

Reuse the same subagents from round one rather than spawning fresh ones — they retain their context and can critique from a position of understanding. Send each author the other proposals (not their own) and ask each for:
  • For each alternative: its pros (what it gets right, where it's stronger than my approach) and its cons (risks, edge cases, hidden costs, wrong assumptions).
  • Whether, having seen the alternatives, they would revise their own recommendation — and why or why not.
  • A final ranking or recommendation with confidence.
Insist on both pros and cons for each alternative. An honest critique that credits a rival's strengths is far more useful than a reflexive defense of one's own proposal.
重用第一轮的同一子代理,而非生成新的代理——他们保留了上下文,能基于理解进行评审。将其他方案(而非他们自己的)发送给每位作者,并要求他们提供:
  • 针对每个替代方案:其优点(做得好的地方、比我的方案更强的点)和缺点(风险、边缘情况、隐藏成本、错误假设)
  • 看到替代方案后,是否会修改自己的建议——以及原因
  • 最终的排名或建议,并说明置信度
要求针对每个替代方案同时提供优点和缺点。承认竞争对手优势的坦诚评审,比盲目捍卫自己的方案有用得多。

3. Synthesize

3. 综合结果

Now bring it together yourself. Compare critiques by evidence quality, not vote count. In your final answer:
  • Lead with the recommendation.
  • Note where the authors converged after seeing each other's work — convergence in round two is a strong signal.
  • Surface the most incisive cons raised against each option.
  • Explain why the recommended option survives critique best against the decision criteria.
  • Call out remaining disagreement, confidence, and material unknowns.
现在由你自行整合结果。依据证据质量而非投票数量来比较评审意见。在最终答案中:
  • 首先给出建议
  • 记录作者们在看到彼此成果后达成共识的地方——第二轮的共识是强烈信号
  • 列出针对每个选项提出的最尖锐的缺点
  • 解释为什么推荐的选项在决策标准下最能经受住评审
  • 指出剩余的分歧、置信度和重要未知因素

Final answer template

最终答案模板

Use this shape unless the task calls for something different:
markdown
undefined
除非任务有特殊要求,否则使用以下格式:
markdown
undefined

Recommendation

建议

[One or two sentences with the decision.]
[一两句话说明决策内容]

How the critiques shifted things

评审带来的变化

  • [Where authors converged or changed their minds after seeing alternatives]
  • [The strongest objection raised, and whether it's decisive]
  • [作者们在看到替代方案后达成共识或改变想法的地方]
  • 提出的最强烈反对意见,以及该意见是否具有决定性

Why this option wins

该选项胜出的原因

  • [Reason grounded in the critiques]
  • [基于评审意见的理由]

Remaining risks and unknowns

剩余风险与未知因素

  • [Open question or caveat]
undefined
  • [未解决的问题或注意事项]
undefined

Practical notes

实用提示

  • Keep the critique round read-only unless the underlying task explicitly involves making changes.
  • Don't expose internal subagent IDs in user-facing summaries unless the user asks.
  • If a critique is thin or unsupported, send a focused follow-up to that same author rather than discarding it.
  • 除非基础任务明确要求修改,否则评审阶段保持只读
  • 除非用户要求,否则不要在面向用户的总结中暴露内部子代理ID
  • 如果评审内容单薄或缺乏依据,向该作者发送针对性的跟进请求,而非直接丢弃