git:20260818.a8b21c0 to git:20261022.af5bf98

---

name: second-opinion

description: "Cross-check the agent's own answer with independent reviewers before bringing it to the user. Use when the user says 'second opinion', 'sanity check', 'cross-check', 'am I missing something', 'stress-test', 'devil's advocate', 'run a full review', 'this is important', 'high-stakes', 'help me choose between', 'critique this', or similar. Three review styles: Devil's Advocate (single critique), Boardroom Debate (parallel multi-reviewer validation), Round-Table (multi-round brainstorm for choosing between paths). Not for factual lookups — use WebSearch for those."

---

# 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.