Run an independent review panel

Some decisions benefit from more than one review, especially when correctness, product behavior, test strategy, and maintainability pull in different directions. Solo can run several reviewers against the same artifact, keep their first passes independent, and wake one lead agent to synthesize the result.

The artifact does not have to be code. The same pattern works for an implementation plan, product spec, documentation set, technical design, or piece of writing.

Decide whether a panel is warranted#

Use one reviewer for a bounded change with one obvious risk. Use a panel when the lenses are genuinely different or when a wrong decision would be expensive.

Two reviewers are a good default. Three is enough for most broad work. A larger panel needs a strong reason and a lead agent that can validate and deduplicate the output.

Useful lens combinations include:

The reviewers should have distinct questions, not different ways of saying “look for bugs.”

Establish one review contract#

Before spawning reviewers, have the lead record the exact target and shared facts. For code, that means a commit, commit range, or exact uncommitted diff. For a document, it means a specific file or frozen revision.

The shared contract should include:

• The intended outcome.
• The exact artifact under review.
• Relevant constraints and repository guidance.
• Known risks and existing validation.
• What reviewers may inspect.
• What they must not change.
• A common findings format.

If the artifact may change during review, say so. The lead must revalidate accepted findings against the final version.

Spawn isolated reviewers#

You can ask the lead agent to run the full panel with one prompt:

Use Solo to run an independent review panel for this exact artifact. Define two
or three materially different lenses and give every reviewer the same target,
intent, constraints, and evidence. Keep the first passes independent and read-only.
Use one consolidated all-idle timer, then validate material claims yourself,
deduplicate overlaps, preserve meaningful disagreement, and return one decision.
Synthesize by evidence, not by vote. Close reviewers after their results are
captured. Do not implement fixes unless I ask.

Each reviewer should receive one lens and the same output contract. Require precise evidence, impact, confidence, and the smallest credible correction. Allow “no material findings.” A panel that requires every seat to invent a concern will create noise on purpose.

If you want to compare review methods, use the same configured agent runtime for every seat so capability differences do not dominate the result. If you want model diversity, let the lead choose different configured agent tools and include the reviewer map in the final report.

Keep the first passes independent#

Do not show one reviewer another reviewer's findings before both initial reports are complete. Early sharing creates anchoring: later reviewers start checking the first opinion instead of examining the artifact.

The lead can give all reviewers the same scratchpad section with shared context, but each reviewer should return its findings through its own process output. Reviewers should not edit a common report, update each other's todos, spawn successor agents, or manage the lead's timers.

After dispatch, the lead should set one timer_fire_when_idle_all timer for the panel. The timer's message should name the reviewer processes, the artifact, and the next action. If one reviewer is still productively working when the maximum wait expires, the lead can set one more consolidated timer rather than interrupting it or polling in a loop.

Synthesize by evidence#

When the panel is ready, the lead should read the actual reports and validate every decision-changing claim. For a code review, that means checking the current code, callers, tests, and diff. For a spec or document, it means checking the cited section and the product behavior it claims to describe.

The lead should then:

1. Reject findings that do not survive direct inspection.
2. Merge findings that describe the same underlying problem.
3. Keep real disagreements visible.
4. Rank correctness, safety, and explicit product constraints above preference.
5. State the condition that would change a context-dependent decision.
6. Recommend the smallest ordered set of follow-ups.

Do not count votes. Three agents can repeat the same shallow assumption, while one agent can find the evidence that changes the decision.

Return one useful report#

A strong synthesis contains:

• The overall verdict.
• Validated findings ordered by severity or importance.
• Evidence, impact, confidence, and smallest correction for each finding.
• Important disagreements and the lead's ruling.
• Missing tests or validation.
• Scope and limitations, including a reviewer that did not finish.
• A short reviewer-to-lens map.

If the review produces follow-up work, ask the lead to turn accepted findings into todos. Capture the reports before closing the reviewer processes.

Panels are especially useful as a saved prompt template. Use a placeholder for the review brief and keep the independence, timer, evidence, and synthesis rules fixed. Change the lenses to fit the artifact instead of maintaining one enormous checklist for every kind of review.