| name | diverge-critique-converge |
| description | Generate high-quality analysis, plans, or designs by running a structured bakeoff. N agents independently produce solutions in isolated worktrees, M critics review each from orthogonal angles, then synthesize the best elements into a composite. Use when the problem is ambiguous, high-stakes, or benefits from multiple perspectives. Triggers: bakeoff, diverge-converge, independent analysis, multi-perspective review, competitive analysis, adversarial review, stress-test a plan. |
Diverge → Critique → Converge
Overview
Produce a high-quality output by preventing anchoring bias. Instead of writing one draft and iterating, generate N independent solutions, stress-test each from M angles, then synthesize.
When to Use
- The problem is ambiguous and multiple valid approaches exist
- The output is high-stakes (architecture decisions, policy documents, migration plans)
- You suspect anchoring bias — a first draft would constrain thinking
- The user wants adversarial review or stress-testing of an idea
- The deliverable benefits from multiple perspectives (security, feasibility, policy, operations)
When NOT to Use
- The task has one obvious correct answer
- Speed matters more than thoroughness
- The problem is too small to justify N agents (single-file change, simple bug fix)
Inputs
Before starting, establish with the user:
- The problem statement — what are we producing? (roadmap, architecture, policy, design)
- The criteria doc — what yardstick do the agents evaluate against? If none exists, create one first and get user agreement. This doc must be committed/available so all agents read the same thing.
- N — how many independent solutions? Default: 5. Use 3 for simpler problems, 5+ for complex ones.
- M — how many review angles per solution? Default: 3. Standard angles: feasibility, completeness, risk. Customize per domain.
- Output location — where does the composite go? Where are bakeoff entries preserved?
Phase 1: Deep Investigation
Before launching the bakeoff, build a thorough understanding of the problem space. This can be done by the orchestrator or delegated to explore agents.
- Read all relevant files, configs, docs
- Understand current state, constraints, dependencies
- Produce or refine the criteria document that all agents will work against
Key output: A criteria doc that is separate from any solution. Agents evaluate against criteria, not against each other.
Phase 2: Diverge (N Independent Solutions)
Launch N agents in parallel, each in an isolated worktree to prevent reading each other's work.
Agent prompt template
You are creating an independent [DELIVERABLE TYPE] for [SUBJECT].
IMPORTANT: Do NOT read or reference [PATH TO EXISTING SOLUTION OR OTHER AGENTS' WORK].
Create your analysis completely independently.
Step 1: Read the criteria document at [PATH TO CRITERIA DOC].
Step 2: Thoroughly investigate [WHAT TO INVESTIGATE].
Read: [LIST OF FILES]
Step 3: Write your [DELIVERABLE] at [OUTPUT PATH] containing:
[STRUCTURE REQUIREMENTS]
Be opinionated. Take positions and defend them. Don't hedge.
Write the file, then stop. Do not commit.
Critical rules
- Worktree isolation is mandatory. Use
isolation: "worktree" on each Agent call. Without it, later agents read earlier agents' output and converge prematurely.
- Explicit exclusion of existing work. Tell agents NOT to read the existing solution, prior drafts, or other agents' files.
- Same criteria doc for all. Every agent reads the identical yardstick.
- Same investigation scope. List the same files for all agents to read so they have equal information.
- Opinionated output. Instruct agents to take positions, not hedge. Hedged outputs produce mush when synthesized.
Failure handling
- Worktree creation can fail due to git lock contention when many launch simultaneously. Retry failed agents after a few seconds.
- Collect outputs from worktree paths:
.claude/worktrees/agent-{id}/[output-path]
- Copy all outputs to the main repo before starting critique phase.
Phase 3: Critique (M Reviews per Solution)
Launch N × M review agents. Each reviews ONE solution from ONE angle.
Standard review angles
| Angle | What it asks |
|---|
| Feasibility | Will each step actually work as described? Flag anything technically incorrect, with unstated prerequisites, or that won't work at runtime. Verify claims against actual files. |
| Completeness | Does this address all criteria dimensions? Are any under-addressed? Does the progression model make sense? Are the "unlocks" at each step realistic? What's missing? |
| Risk | Does this honestly assess what's lost? Is the classification defensible? Are there security, operational, or organizational risks ignored? Is the supply chain story adequate? |
Customizable angles (pick based on domain)
- Operational realism — will this survive contact with production?
- Policy alignment — does this satisfy the organizational framework?
- Security — supply chain, blast radius, failure modes
- Missing perspectives — what blind spots exist?
- Cost/effort accuracy — are estimates realistic?
Review agent prompt template
You are reviewing a [DELIVERABLE TYPE]. Read these two files:
1. [CRITERIA DOC PATH]
2. [SOLUTION PATH]
Also read [RELEVANT REPO FILES] to verify claims.
Your review angle is **[ANGLE]**. [ANGLE-SPECIFIC INSTRUCTIONS]
DO NOT edit any files. Return your review as plain text in your response.
Performance tips
- Use
model: "haiku" for review agents — they're focused critique tasks, not creative work. This saves significant cost and time.
- Launch all N × M agents in a single message for maximum parallelism.
- Review agents don't need worktree isolation — they're read-only.
Phase 4: Converge (Synthesis)
Read all N solutions and all N × M reviews. Produce a composite that:
Extract consensus
What do all/most solutions agree on? These are high-confidence findings. Document them as settled positions.
Identify disagreements
Where do solutions diverge? For each disagreement:
- State both positions
- Note which reviews supported/challenged each
- Make a decision and document the rationale
Cherry-pick unique contributions
Each solution will have ideas the others missed. Scan for these and incorporate the best ones.
Apply review corrections
Reviews will flag things that are wrong (infeasible steps, incorrect claims, missing dimensions). Apply these corrections to the composite.
Structural synthesis
- Ordering: Multiple solutions may propose different step orderings. The reviews (especially risk reviewers) will often flag ordering problems. Use their feedback.
- Scope: Some solutions will be more ambitious than others. The composite should match the user's appetite — ask if unclear.
- Honest tradeoffs: Include a section on what is lost, not just what is gained. Multiple risk reviewers will surface this.
Preserve provenance
Keep the bakeoff entries and reviews alongside the composite so the reasoning chain is auditable:
docs/
[topic]/
[composite].md # The final synthesized output
[criteria].md # The shared yardstick
bakeoff/ # Independent solutions
solution-a.md
solution-b.md
...
reviews/ # Critiques (if preserved as docs)
...
Reporting
After each phase, give the user a status update:
After diverge: "N agents complete. Here's a one-line summary of each approach."
After critique: "N×M reviews complete. Here are the consensus findings and key disagreements."
After converge: "Composite produced. Here's what changed from the original approach and why."
Scaling Guidance
| Problem complexity | N (solutions) | M (review angles) | Total agents |
|---|
| Simple (single doc, clear criteria) | 3 | 2 | 9 |
| Medium (multi-step plan, some ambiguity) | 5 | 3 | 20 |
| Complex (architecture, policy, high-stakes) | 5 | 5 | 30 |
Common Mistakes
| Mistake | Fix |
|---|
| Agents read each other's work | Use worktree isolation; explicitly tell agents not to read other outputs |
| No criteria doc — agents invent their own yardstick | Always create and agree on criteria before diverge phase |
| Reviews are too gentle ("this is good but...") | Instruct reviewers to be direct; use angle-specific prompts that force hard questions |
| Composite is just the longest solution | Synthesize across all; the shortest solution may have the best idea |
| Skipping provenance | Keep bakeoff entries; the user may want to revisit individual perspectives |
| Using opus for review agents | Use haiku — reviews are focused critique, not creative generation |
| Launching all agents in one message and hitting rate limits | Launch in batches of 5-8 if needed |
