
cross-critique
Run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision — architecture tradeoffs, code review disagreements, design choices, competing root-cause theories — and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills; reach for it liberally whenever proposals diverge.
- Installs
- 21.9K
- Last 24h
- +31
- Trending rank
- #4327
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/warpdotdev/common-skills --skill cross-critique- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads cross-critique automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
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:
## 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.
FAQ
What does the cross-critique skill do?
Run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision — architecture tradeoffs, code review disagreements, design choices, competing root-cause theories — and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills; reach for it liberally whenever proposals diverge.
How do I install cross-critique?
Run npx skills add https://github.com/warpdotdev/common-skills --skill cross-critique in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/cross-critique/ (personal) or .claude/skills/cross-critique/ (project).
Which AI agents can use cross-critique?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is cross-critique safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains cross-critique?
It is published by warpdotdev in warpdotdev/common-skills. It has 21,918 recorded installs.
More from warpdotdev/common-skills
review-pr
warpdotdev/common-skills
Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like prdiff.txt and prdescription.txt and producing machine-readable review output instead of posting directly to GitHub.
spec-driven-implementation
warpdotdev/common-skills
Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.
write-product-spec
warpdotdev/common-skills
Write a PRODUCT.md spec for a significant user-facing feature in Warp, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.
write-tech-spec
warpdotdev/common-skills
Write a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.
resolve-merge-conflicts
warpdotdev/common-skills
Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when git status shows unmerged paths, or when files contain conflict markers.
fix-errors
warpdotdev/common-skills
Fix compilation errors, linting issues, and test failures in the warp Rust codebase. Covers presubmit checks, WASM-specific errors, and running specific tests. Use when the user hits build errors, clippy or fmt failures, test failures, or needs to run or interpret presubmit before a PR.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.