second-opinion

Second Opinion (LLM Council)

Independent, multi-model work — either a review of material the user provides or the work itself — turned into decisions. Any single model — including the one running this conversation — has consistent blind spots. Routing the same brief through models from different families surfaces disagreements, missed issues, and overstated claims that one model alone won't catch.

Four principles govern this skill:

1. Secondary tool. By the time this skill runs, Claude has already given its opinion in the main conversation. The skill exists to bring in independent outside views — it does not replace or re-run Claude's upstream analysis.
2. The council is the non-Claude bench by default. Council members are models from families other than the orchestrator (Gemini, DeepSeek, GPT, etc.). Claude is not a first-opinion council member unless the optional "Claude in the council" toggle is on — and even then it is judged but does not vote or chair.
3. Claude orchestrates; Claude does not synthesize the verdict. Claude preps material, recommends the council, drives the run, presents accept/deny decisions, and applies them. A designated non-Claude chair model synthesizes the final verdict. Claude's role ends at presenting it.
4. The subject of cross-review is the other reviews, not the artifact again. In the peer cross-review stage, models critique and rank each other's reviews — not re-review the original artifact (in task mode: each other's responses; the subject is never the briefing again). This is the mechanism that surfaces reviewer blind spots and inflated confidence.

Two intents, one machine (v4.9). The council runs in one of two intents, and choosing between them is a Stage-0 decision, not a wording preference:

• Review (default). The user supplies material and the bench reviews it against criteria. Seats raise findings; judges rank how accurate each review was; the chair closes VERDICT: Ship it | Fix these first | Fundamental rethink.
• Task (--intent task). The user asks for work to be DONE, and the bench does it — each seat independently produces the analysis, answer, or artifact the briefing requests, plus the load-bearing claims it rests on. Judges rank the responses by how well each did the work and adjudicate those claims; the chair synthesizes an ANSWER across them and closes ANSWER: Converged | Split | Insufficient.

Everything else is shared: same seats, same anonymized bundle, same tier machinery (though a tier means peer concurrence on a task run, not peer verification of a defect), same commands, same artifacts under the same filenames (a seat's deliverable still lands in review-<seat>.md). Task mode is not a lesser mode or a fallback — see Key mechanics → §5.5.

The engine runs the mechanics (v4.1). Stages 1–3 and the deterministic Stage-5 artifacts are ONE amicus council run call: the engine composes every model-facing briefing, runs the review wave, validates and repairs findings blocks, anonymizes into the judge bundle, runs the cross-review wave, optionally runs the rebuttal round, tallies (appending the reliability ledger once), chairs, and writes verdict.json + report.html. Claude owns the human stages — Stage 0 (intake and briefing), Stage 4 (tiered decisions), Stage 5 (apply and present), Stage 6 (lessons). The hand-orchestrated mechanics still exist, in MANUAL-ORCHESTRATION.md next to this file, as the documented fallback.

Operating lessons from each run fold back into MODEL-NOTES.md (with approval), so the skill gets better at driving each model over time.

Before launching any model, READ MODEL-NOTES.md (next to this file). It holds the operating rules and per-model quirks that decide whether a run succeeds or silently fails. These were learned the hard way; skipping them wastes runs and produces empty results that look like answers.

Transport rule — CLI not on PATH: every command below assumes the amicus CLI. If amicus is not on PATH (typical for plugin-only installs), run the identical commands as npx -y amicus@latest <args> (e.g. npx -y amicus@latest council run --prompt-file <path> --models "m1,m2,m3" --json), or use the equivalent MCP tools (amicus_council_run, amicus_wait, amicus_status, amicus_verdict, amicus_council_stats, plus amicus_fanout / amicus_start / amicus_read for the manual fallback) — council briefings are always self-contained, so MCP transport is equivalent.