Table of Contents

• What is Amicus
• The Council
• Ways to run the council
• Quick start
  • 1. Install
  • 2. Configure — don't skip this
  • 3. Your first council
  • 4. Your first sidecar
• Requirements & Dependencies
• The parallel window
• Commands
• Models
• MCP integration
• Configuration
• JSON output
• Windows
• Troubleshooting
• Documentation
• Contributing
• Built on OpenCode
• Attribution & License

What is Amicus

One install delivers six things that work together:

• The second-opinion LLM Council skill. Structured multi-model review: independent reviews → anonymized peer cross-review → a non-Claude chair verdict → tiered accept/deny decisions. This is the hero.
• The sidecar chat skill. Ad-hoc fork/work/fold — spin up one other model in a real window (or headless), work alongside it, fold the summary back.
• The amicus CLI (with an am alias) and an MCP server. The engine underneath both skills: launches sessions, shares context, runs parallel waves, and exposes the same surface to Claude as MCP tools.
• A self-updating model catalog. Aliases and validation resolve against a live catalog fetched from provider APIs (cached locally), so model names stay current without a hard-coded table.
• Observability. amicus watch <id> renders any live or finished run (fan-out or council) from any terminal; --follow streams milestones as they happen; --on-complete fires a hook when a run lands; --retry-failed plus opt-in cheaper-model fallbacks recover dead legs without relaunching the whole wave; amicus spend answers "what did this cost, and where" with per-run attribution.
• Council Workspace. amicus watch <runId> --ui: a window that shows a council thinking — live seats, the anonymized judge packet, the adjudication matrix, dissent drill-in, chair verdict, and cost-by-seat — for both live and historical runs. It also auto-opens on an MCP-invoked council run from Claude Code (local), so you no longer have to remember the flag (see docs/council.md).

Claude is the orchestrator. The council and chat skills run on top of the engine; you talk to Claude, and Claude drives Amicus.

The Council

Trigger it by saying "council review this" to Claude, or, on the plugin channel, run /amicus:council directly.

Why multi-model. Any single model — including the one running your session — has consistent blind spots. Route the same material through models from different families and the disagreements surface: missed issues, overstated confidence, claims one model alone would have waved through. The council is the structured version of that idea.

The flow, in five beats:

1. Independent reviews. Each council model reviews the artifact on its own (one parallel wave), producing a structured findings list — claim, severity (blocker | major | minor | nit), location, rationale.
2. Anonymized cross-review. Claude relabels every review (Review A, B, C…) and sends the identical bundle to every model. Each model ranks the reviews and adjudicates every finding (agree | dispute | neutral) — unknowingly judging its own, so self-bias washes out. This yields a street-cred ranking and sorts findings into Disputed / Confirmed / Contested / Singleton tiers. Self-bias is washed out per seat: if you deliberately seat one model twice, each seat's vote on the other seat's finding is counted as the real peer vote it is, and the finding is flagged when its only corroboration came from its own twin.
3. Chair verdict. A designated non-Claude chair receives the de-anonymized picture — all reviews, rankings, and adjudications — and synthesizes an independent verdict. Claude presents it verbatim; Claude does not synthesize.
4. Tiered decisions. Confirmed findings get one bulk accept/deny; Contested and Singleton findings are decided one at a time (accept / deny / modify).
5. Outputs applied. Accepted findings are written into a reviewed copy of the source; the full run is captured in the run folder.

flowchart LR
    A["Artifact"] --> B["Independent<br/>reviews"]
    B --> C["Anonymized<br/>cross-review"]
    C --> D["Chair verdict<br/>(non-Claude)"]
    D --> E["Tiered<br/>accept / deny"]
    E --> F["Reviewed copy<br/>+ run folder"]

What a run produces (in output/<stem>-council/):

• review-<model>.md × N — each model's independent review.
• crossreview-matrix.md — the adjudication grid plus the de-anonymized street-cred table.
• verdict.md — the chair's synthesis.
• report.md — synthesis + the full decision log + a per-call run-stats table.
• report.html — the deterministic renderer output (adjudication matrix, street-cred table, findings-by-tier, cost — no chair prose). This is the default artifact handed to the user.
• For an editable source, the accepted edits land in <stem>-reviewed.<ext> next to the original.

Optional council elements (v2.2.0, all default off): four opt-in behaviors, offered once as a menu at launch — nothing turns on unless you name it, and the confirmation lists exactly what's on. Chair verdict scale (standard since v2.2.0's follow-ups — no longer opt-in): the chair always closes with 3–5 hard questions and one parseable VERDICT: Ship it | Fix these first | Fundamental rethink line.

• Critic seat — one reviewer swaps to a four-pass adversarial brief (adversarial pass, edge-case hunt, consistency check, executability test). Its findings enter the same anonymized bundle as everyone else's, so the bench disciplines the critic: manufactured negativity lands Disputed and dies in the tally.
• Expert lenses — each reviewer takes a distinct expert perspective; you pick the panel domain (business, technical, customer, financial, or custom). Lens runs never feed the reliability ledger, and the report discloses the weakened cross-review anonymity.
• Debate mode — after cross-review, every Contested or Disputed finding goes back to its raiser to defend, amend, or withdraw, and the disputing judges re-vote. Exactly one rebuttal round, then the final tally.
• Claude in the council — Claude adds its own fresh review to the bundle so the bench ranks and adjudicates it. Claude is judged but never votes or chairs, so the verdict stays independent.

The critic and lens methodologies are adapted from the /critic and /debate agents in John Renaldi's product-kit (MIT); the briefing boilerplate lives in skills/second-opinion/SEAT-BRIEFS.md.

Cost is disclosed up front. Before any model launches, you see the run shape — including any enabled optional elements — for example: