Second Opinion

Second Opinion — cross-check before you commit

Stress-test your own answer with reviewers who don't share your framing. The reviewer set depends on what you have available:

• Always available: the isolated idea-validator agent (same model family, but NO parent context — it can't anchor on your framing, and it READS the actual files).
• If you have access to a second model family (Gemini, GPT, …, via a CLI wrapper or API): add it as an external reviewer. A different training distribution catches different blind spots. It reviews from the brief only (no repo access) — lean on it for concept and tech-currency, not file-level facts.

When to invoke

1. Two or more viable paths to choose between → Round-Table.
2. High-stakes decision (architecture, launch copy, anything with real rollback cost) → Boardroom Debate.
3. Stuck on the same problem after 2+ attempts, or a non-trivial proposal awaiting approval → Devil's Advocate.

If none fires, don't invoke — a single-model answer is enough for routine work. Out of scope: factual lookups ("what's the latest X") — that's WebSearch, not review.

Own thinking first (load-bearing)

Before ANY review style: do your own research, form your own proposal with rationale and trade-offs, show it to the user. Only then invoke reviewers to critique it. Asking a reviewer before forming your own position turns it into a seed for the decision instead of a validator — and a reviewer without your codebase context can confidently seed something wrong.

The three styles

1. Devil's Advocate (single critique)

Spawn idea-validator with a self-contained artifact (the design/decision/plan pasted inline, plus the file paths it should actually read). Or send the same artifact to your external model if the claim is about tech or the outside world.

2. Boardroom Debate (parallel validation — the headline pattern)

1. Write ONE self-contained artifact. Paste content inline — never rely on file references a brief-only reviewer might silently fail to load.
2. Launch ALL reviewers in the SAME message (parallel calls). Sequential calls destroy independence — a later reviewer sees the earlier one's framing.
3. Build an acceptance ledger: | Concern | Reviewer A | Reviewer B | My evaluation | Action |
4. Adjudicate, never count votes. All agreeing can share a blind spot; one dissenter with a file:line beats abstract agreement. A code-reading reviewer outranks a brief-only one on facts about the code. The procedure in full — the three acceptance layers and the claim→cheapest-decisive-check table — is reference/orchestrator-fact-check.md.
5. Present the ledger critically: where you accept, where you push back, and why. You make the final call — reviewer output is INPUT, not the decision.

3. Round-Table (choosing between paths)

Diverge → deepen → converge, with a mandatory user check-in before convergence: ground the facts (web-check) → generate/challenge options broadly → kill weak ones down to 2-3 with concrete arguments → present survivors to the user, ask for preference → converge on one primary + a kill list → fact-check the final claims → synthesize.

Critical evaluation rule

After every reviewer call: challenge each recommendation (fact or speculation?), check for missing context the reviewer couldn't see, verify numbers (predictions are not measurements), and present a table — reviewer said / my evaluation / action.

Anti-patterns: forwarding reviewer output as-is · accepting everything · treating reviewer confidence as correctness · running reviews for trivial/stylistic choices · sequential "parallel" calls.