---
id: gh-cross-critique
name: "cross-critique"
url: https://skills.yangsir.net/skill/gh-cross-critique
author: warpdotdev
domain: ai-software-architecture-engineering
tags: ["software-architecture", "code-review", "decision-making", "agent-collaboration", "critical-analysis"]
install_count: 21800
rating: 4.60 (120 reviews)
github: https://github.com/warpdotdev/common-skills/tree/main/.agents/skills/cross-critique
---

# cross-critique

> 此技能通过让多个独立智能体相互评审提案，对有争议的决策进行第二轮分析。它要求每个智能体提供其他提案的优缺点，从而发现潜在风险和更深层次的权衡。该 Skill 适用于架构设计、代码审查分歧或根因分析等复杂工程问题，能产出比单独综合更深入、更全面的分析结果，提升决策质量。

**Stats**: 21,800 installs · 4.6/5 (120 reviews)

## Before / After 对比

### 降低决策风险

**Before**:

在没有此技能之前，用户在面对多个独立但有争议的提案时，手动综合分析容易遗漏关键风险点和潜在问题，导致决策质量不高，后期可能需要大量返工或承担意外后果。

**After**:

此技能通过引导智能体进行交叉评审，系统性地识别并揭示各提案的优缺点、潜在风险和隐藏假设，大幅减少决策中的盲点，使最终决策更加全面和稳健。

| Metric | Before | After | Change |
|---|---|---|---|
| 决策风险点 | 10个 | 2个 | -80% |

## Readme

# 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.

## 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.

## 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.

## How to do it

### 1. Assemble the proposals

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.

### 2. Circulate and ask for structured critique

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

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
## 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]
```

## 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.


---
*Source: https://skills.yangsir.net/skill/gh-cross-critique*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-cross-critique/markdown*