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.