amicus 2.0.0 → 2.2.0

package/skills/second-opinion/SEAT-BRIEFS.md

@@ -0,0 +1,190 @@
+# Seat Briefs — Optional Council Elements
+
+Briefing boilerplate for the **optional council elements** offered at Stage 0 of the
+`second-opinion` skill (SKILL.md → "Optional council elements"). When an element is toggled
+ON, Claude copies the relevant block below into the run's `_tmp-*` briefing files and fills
+the `<placeholders>`. Everything here is orchestration prose — the findings contract,
+`council validate`, tally, and verdict mechanics are unchanged unless a section says
+otherwise.
+
+_The critic and lens methodologies are adapted from the `/critic` (elite-advisor) and
+`/debate` (expert-debate-facilitator) agents in John Renaldi's product-kit plugin (MIT)._
+_Deliberate deviations from those sources: no minimum-findings quota (quotas force invented
+findings, which waste the bench's adjudication capital), and the hard questions +
+Ship/Fix/Rethink verdict belong to the chair (synthesis-level judgments stay with the
+non-Claude chair, per the council's core rule)._
+
+---
+
+## Standard anti-sycophancy clause (ALL Stage-1 briefings — not an optional element)
+
+Include this block **verbatim in every Stage-1 review briefing**, standard seats included.
+This is briefing hygiene, not a toggle:
+
+> Do not soften findings to be agreeable. Lead with your most severe finding. No praise
+> cushions before criticism, and never perform enthusiasm you don't hold — if the artifact
+> is mediocre, say so and show why. Do not pad: report every real finding and no invented
+> ones. An empty severity category is a valid result.
+
+---
+
+## Critic seat brief
+
+Body of `_tmp-briefing-critic.md`. Follow it with the standard structured-output contract
+(prose review + trailing findings JSON, identical to every other seat) and the material.
+One bench member gets this brief **instead of** the standard review brief; the rest of the
+bench runs the normal fanout wave.
+
+> You are this review bench's designated critic. Assume problems exist; your job is to find
+> them, not to confirm the artifact is fine. Work through four passes and fold everything
+> into one findings list:
+>
+> 1. **Adversarial pass** — for every claim: what evidence supports it, or is it an
+>    assumption presented as fact? For every goal: is it measurable — would the author know
+>    if they hit it or missed it? For every decision: what alternatives were considered, or
+>    was this just the first idea? For every scope boundary: real constraint, or avoidance
+>    of hard work?
+> 2. **Edge-case hunt** — walk every journey, requirement, and scenario. What happens on the
+>    unexpected input, the failed integration, the malformed data? At zero, at one, at
+>    scale? With the confused, frustrated, or adversarial user instead of the happy-path
+>    one? Report only unhandled cases — if the artifact addresses an edge case, move on
+>    silently.
+> 3. **Consistency check** — cross-reference sections against each other: do goals have
+>    metrics, and metrics targets? do requirements trace back to stated needs? do the
+>    milestones fit the declared scope? does anything contradict a stated non-goal or
+>    constraint?
+> 4. **Executability test** — could someone act on this artifact without coming back with
+>    clarifying questions? Wherever the answer is no, name the specific section and exactly
+>    what is missing.
+>
+> Be specific: name the section, the line, the exact gap — not "the requirements need work"
+> but which requirement, and what about it is untestable. Report every real finding and no
+> invented ones; do not pad to look thorough. An empty pass is a valid result.
+
+**Orchestration notes (not part of the brief):**
+- Launch as a separate concurrent solo run alongside the fanout wave — the exact red-team
+  variant pattern in SKILL.md Stage 1.
+- Same findings contract, same `council validate` + repair loop, same anonymization into the
+  Stage-2 bundle. Judges are never told a critic seat exists.
+- Record `role: "critic"` on the seat's `runStats` entry.
+- Disclose in `report.md`: the critic model can recognize its own review in the Stage-2
+  bundle by its adversarial shape, so self-bias wash-out is weakened for that one seat.
+
+---
+
+## Expert lens briefs
+
+**Panel scoping first (Stage 0, when the element is toggled ON).** Ask the user which
+domain the panel should come from, then propose one distinct lens per seat:
+
+- **Business / Venture** — VCs, operators, market strategists (viability, positioning, GTM)
+- **Technical** — architects, security specialists, infrastructure engineers (feasibility,
+  scalability, build-vs-buy)
+- **Specialty technical** — user names the field (ML, biotech, regulatory, hardware, …)
+- **Customer / Market** — user researchers, skeptical buyers, channel partners (demand,
+  willingness to pay, adoption barriers)
+- **Financial** — CFOs, pricing strategists, unit-economics experts
+- **Mixed / Custom** — the user defines the lens set
+
+Pick lenses that will produce productive tension (a growth-stage VC + a bootstrapped
+operator + a skeptical enterprise buyer beats three near-identical strategists). Confirm the
+lens set with the user before launch.
+
+**Per-seat brief opener** (`_tmp-briefing-lens-<slug>.md`, one per seat; follow with the
+standard structured-output contract and the material):
+
+> Review this artifact strictly through the lens of a <lens — e.g. "growth-stage VC",
+> "security architect", "skeptical enterprise buyer", "CFO focused on unit economics">.
+> Raise only findings that perspective is qualified to raise, at the depth a top
+> practitioner of it would reach. Stay in-domain: if something matters but is outside your
+> lens, leave it to the other reviewers.
+
+**Orchestration notes (not part of the brief):**
+- Every seat gets a distinct brief, so there is no shared-prompt wave — launch ALL legs as
+  concurrent solo runs.
+- The lens↔model assignment is random and lives only in the private label map. Never tell
+  any reviewer which lenses the other seats hold, and never mention lenses in the Stage-2
+  bundle or judging instructions — judges rank on accuracy and insight only.
+- Record `role: "lens:<slug>"` on each `runStats` entry.
+- The Stage-2 tally runs `--no-ledger` — lens reviews are not comparable to standard
+  reviews, so they must not feed cross-run reliability stats.
+- Disclose in `report.md`: anonymity is weakened (each judge can spot its own lens-flavored
+  review), street-cred is not comparable across lenses, and the run was not recorded to the
+  reliability ledger.
+
+---
+
+## Rebuttal-round templates (debate mode, Stage 2.5)
+
+### Defense brief
+
+`_tmp-rebuttal-<label>.md` — one concurrent solo run per raiser that has at least one
+Contested or Disputed finding. First line is the no-tools preamble, verbatim:
+
+> Do NOT use any tools or read any files; everything is in this message; begin immediately
+> with the first finding id.
+>
+> You reviewed an artifact and raised the findings below. Peer reviewers (anonymous)
+> disputed them for the stated reasons. For EACH finding, respond with exactly one line
+> starting with the finding id and one verb:
+>
+> `<id>: DEFEND — <your strongest evidence-based defense, one paragraph maximum>`
+> `<id>: AMEND — <the corrected claim, full replacement text>`
+> `<id>: WITHDRAW`
+>
+> Withdraw anything you cannot defend with evidence — an unsupported repeat of the original
+> claim is weaker than a withdrawal.
+>
+> [one block per finding: id · claim · severity · the peers' dispute reasons, anonymized]
+
+### Re-vote bundle
+
+`_tmp-revote-bundle.md` — ONE shared bundle, sent as a single fanout wave to every judge
+that disputed at least one defended or amended finding. First line is the no-tools preamble,
+verbatim:
+
+> Do NOT use any tools or read any files; everything is in this message; begin immediately
+> with the first finding id.
+>
+> You previously adjudicated the findings below and disputed them. The (anonymous) raiser
+> has now responded. Re-adjudicate ONLY these findings in light of the response. For each,
+> respond with exactly one line:
+>
+> `<id>: agree | dispute | neutral — <one-line reason>`
+>
+> Changing your verdict when the defense is convincing is good judging, not weakness; so is
+> holding your dispute when it isn't.
+>
+> [one block per finding: id · claim (amended claims marked AMENDED) · the raiser's
+> defense]
+
+**Orchestration notes (not part of the briefs):**
+- Exactly ONE rebuttal round, ever. Whatever remains unsettled after the re-vote keeps its
+  final tier.
+- A missing or unparseable defense line = the original claim stands undefended. A missing
+  re-vote line = that judge's original verdict stands.
+- WITHDRAWN findings stay in the tally input (they were raised) and are auto-recorded as
+  `denied` in Stage 4 — never presented for a user decision. List them in `report.md` under
+  "Withdrawn by raiser (debate mode)".
+
+---
+
+## Chair verdict-scale addendum
+
+Append to the chair packet (`_tmp-chair-packet.md`) when the element is toggled ON:
+
+> After your synthesis, add two closing sections:
+>
+> 1. **HARD QUESTIONS** — three to five questions the artifact's author has probably not
+>    asked themselves, chosen so that an unanswerable question reveals a structural gap in
+>    the artifact (not gotchas — questions whose answers should exist).
+> 2. A final line, alone on the last line, in exactly this format:
+>
+>    `VERDICT: Ship it` | `VERDICT: Fix these first` | `VERDICT: Fundamental rethink`
+>
+>    Pick one. "Ship it" = solid, nothing blocking. "Fix these first" = specific gaps must
+>    be resolved before the artifact is useful — name them. "Fundamental rethink" =
+>    structural problems that cannot be patched — say what is wrong at the foundation.
+
+**Orchestration note:** surface the chair's `VERDICT:` line verbatim at the top of
+`report.md` and in the inline chat presentation of the results.

package/skills/second-opinion/SKILL.md

@@ -31,7 +31,7 @@ Operating lessons from each run fold back into `MODEL-NOTES.md` (with approval),
 
 **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 fanout --models "m1,m2,m3" --prompt-file <path> --json`), or use the equivalent MCP tools (`amicus_fanout`, `amicus_start`, `amicus_status`, `amicus_read`, `amicus_council_tally`, `amicus_council_stats`, `amicus_verdict`) — council briefings are always self-contained (`--no-context`), so MCP transport is equivalent.
+**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 fanout --models "m1,m2,m3" --prompt-file <path> --json`), or use the equivalent MCP tools (`amicus_fanout`, `amicus_start`, `amicus_wait`, `amicus_status`, `amicus_read`, `amicus_council_tally`, `amicus_council_stats`, `amicus_verdict`) — council briefings are always self-contained (`--no-context`), so MCP transport is equivalent.
 
 ## When to use
 
@@ -50,7 +50,7 @@ Operating lessons from each run fold back into `MODEL-NOTES.md` (with approval),
 
 ## The council flow
 
-The flow runs as a **Stage 0 intake/prep step** followed by **three sequential review waves** (Stage 1 → Stage 2 → Stage 3), each wave dependent on the prior. Within each wave, models run in parallel. Track the stages as todos and do not advance until the prior wave's outputs are in hand.
+The flow runs as a **Stage 0 intake/prep step** followed by **three sequential review waves** (Stage 1 → Stage 2 → Stage 3), each wave dependent on the prior — plus an optional **Stage 2.5 rebuttal round** when debate mode is on. Within each wave, models run in parallel. Track the stages as todos and do not advance until the prior wave's outputs are in hand.
 
 ### Stage 0 — Intake & prep
 
@@ -73,7 +73,7 @@ in this run is written here. Use its absolute path in all `--prompt-file` argume
   know "today" and have raised false "future-dated" blockers; state the date explicitly, e.g.
   "Today's date is YYYY-MM-DD."
 
-**Pick the council.** Default: **3 models from different families (non-Claude)**. Recommend them ranked by fit, consulting both the reviewer-reliability data from `amicus council stats` (the authoritative quantitative source — runs, avg peers-only street-cred, confirm-rate, fact-error rate) and the qualitative quirks in `MODEL-NOTES.md`. State the estimated cost. The estimate is the budget gate's pre-flight figure (per-$/Mtok pricing from the cached catalog; direct-provider legs without catalog pricing are disclosed as "cost unknown"). State it as an estimate, not a guarantee. **Disclose the run shape up front** before asking for confirmation — e.g.:
+**Pick the council.** Default: **3 models from different families (non-Claude)**. Recommend them ranked by fit, consulting both the reviewer-reliability data from `amicus council stats` (the authoritative quantitative source — runs, avg peers-only street-cred, confirm-rate, fact-error rate) and the qualitative quirks in `MODEL-NOTES.md`. State the estimated cost. The estimate is the budget gate's pre-flight figure (per-$/Mtok pricing from the cached catalog; direct-provider legs without catalog pricing are disclosed as "cost unknown"). State it as an estimate, not a guarantee. **Disclose the run shape up front** before asking for confirmation — naming any enabled optional council elements and their cost impact (see the optional-elements menu below) — e.g.:
 
 **Free council (zero-cost).** If the user asks for a "free council" / "zero-cost council",
 read `councils.free` from `~/.config/amicus/config.json` and run
@@ -93,6 +93,10 @@ read `councils.free` from `~/.config/amicus/config.json` and run
 
 > This run uses 3 council models across 2 fanout waves + 1 chair call (~7 model runs), ~10 min.
 
+or, with elements enabled:
+
+> This run uses 3 council models across 2 fanout waves + 1 chair call, with **critic seat + debate mode ON** (~7 base runs + up to 6 rebuttal calls), ~15 min.
+
 Then **wait for confirmation**. Never launch without it. The budget gate enforces the cost guardrail in code: by default it refuses any leg whose price exceeds the per-$/Mtok threshold (the o3/o3-pro guard). To run an intentionally expensive model the user explicitly asked for by name, pass `--no-cost-gate`; to raise only the total ceiling, pass `--max-cost <$>`.
 
 **Scale-down is explicit — state which mode applies:**
@@ -102,11 +106,27 @@ Then **wait for confirmation**. Never launch without it. The budget gate enforce
 
 The scale-down levels count **non-Claude judges**; enabling "Claude in the council" adds a judged review but not a judge, so it does not change these levels. If the bench drops below 2 surviving reviews during the run, apply the Stage-1 wave-degrade rule (offer re-run or a disclosed single-pass downgrade).
 
-**Present the "Claude in the council" toggle (default: off).** At launch, offer:
+**Present the optional council elements (all default OFF — explicit opt-in only).** After the
+bench and chair are picked and before asking for launch confirmation, present this menu once
+(adjust the run-shape numbers to the actual bench):
+
+> Optional council elements — all OFF unless you name them. Reply with any you want (e.g. "1 and 3", "critic + debate mode", or "none"):
+>
+> 1. **Critic seat** — one reviewer swaps to an adversarial brief (adversarial pass, edge-case hunt, consistency check, executability test). Same review count; that seat runs as a solo call. Trade-off: that reviewer can recognize its own review during cross-review (disclosed in the report).
+> 2. **Expert lenses** — each reviewer gets a distinct expert perspective; you pick the panel domain (business, technical, customer, financial, custom). Same review count, launched as solo calls. Trade-offs: weakens cross-review anonymity (disclosed) and the run is not recorded to the reliability ledger.
+> 3. **Debate mode** — after cross-review, Contested and Disputed findings go back to their raisers to defend, amend, or withdraw, and the disputing judges re-vote before the final tally. Adds 1–2 short waves (up to ~2N extra calls, ~+5 min).
+> 4. **Chair verdict scale** — the chair ends its synthesis with `VERDICT: Ship it | Fix these first | Fundamental rethink` plus 3–5 hard questions. No extra calls.
+> 5. **Claude in the council** — I add my own fresh review to the bundle so the bench can rank and adjudicate it; I'm judged but do not vote (Stage 2) or chair (Stage 3), so the verdict stays independent. +1 review in the bundle, no extra council calls.
 
-> Claude-in-the-council (default off): I can add my own fresh review to the bundle so the bench can rank and adjudicate it. You'd see how my take compares to the other reviewers. This means Claude is judged but does not vote (Stage 2) or chair (Stage 3) — the verdict stays independent. Turn on?
+Rules for this menu:
 
-When off, Claude does not contribute a review and does not appear in the bundle. When on, see Stage 1.
+- **Never enable an element the user did not explicitly name.** Silence, "no", or "none" = all off. Do not infer opt-in from the nature of the material ("this doc could use a critic…") — offer, don't decide.
+- If elements were **pre-requested in the invoking command** (e.g. `/council … with a critic seat and debate mode`), confirm them back by name ("Critic seat and debate mode are ON per your request; the others are off") instead of re-asking.
+- **The launch confirmation must enumerate the enabled elements by name** — an element not named in the confirmation is off. Restate its cost/shape impact there (see the run-shape disclosure above).
+- Elements compose freely, with one exception: **critic seat + expert lenses together** means one bench member takes the critic brief and the *remaining* seats take lenses — never stack both briefs on one seat.
+- Briefing boilerplate for elements 1–4 lives in **`SEAT-BRIEFS.md`** next to this file — read it when any of them is toggled on.
+
+When Claude-in-the-council is off, Claude does not contribute a review and does not appear in the bundle. When on, see Stage 1 and §5.4.
 
 ---
 
@@ -124,7 +144,7 @@ Always quote the `--models` list — unquoted, PowerShell splits on commas and t
 
 Run it in the background (`run_in_background: true`); you are notified on completion — do not
 poll. `fanout` is headless by definition. The command exits when every leg is terminal and prints
-ONE JSON wave document on stdout (`schemaVersion: 1`; the wave's id field is `waveId`, each leg's id is `taskId`): check `status` (`complete` | `partial` |
+ONE JSON wave document on stdout (`schemaVersion: 2`; the wave's id field is `waveId`, each leg's id is `taskId`): check `status` (`complete` | `partial` |
 `error`), `counts`, and each leg in `legs[]` — a leg's `summary` field IS that model's review;
 `model`/`modelInput` identify the reviewer (`model` is the resolved id, `modelInput` the alias you passed — use the alias for `review-<model>.md` filenames); `status`/`error` identify failures. Exit code 0 =
 all legs complete, 2 = partial (apply the wave-degrade rules below), 1 = error/aborted. (To re-fetch a single leg later: `amicus read <taskId> --json`.)
@@ -140,10 +160,15 @@ amicus start --model <redteam-model> --no-ui --json \
 
 Its stdout is a single run document; the `summary` field is the review.
 
+**Critic seat (optional element, when ON):** one bench member — recommended by Claude at Stage 0, typically a strong reasoner that is not the chair — receives the critic brief from `SEAT-BRIEFS.md § Critic seat brief` **instead of** the standard review brief. Launch it exactly like the red-team variant: a separate concurrent solo run (`_tmp-briefing-critic.md`) alongside the fanout wave of the remaining members — same total review count. Everything downstream is unchanged: same structured-output contract, same `council validate` + repair loop, same anonymization into the Stage-2 bundle (judges are never told a critic seat exists). Record `role: "critic"` on that seat's `runStats` entry. One standing disclosure for `report.md`: the critic model can recognize its own review in the Stage-2 bundle by its adversarial shape, so self-bias wash-out is weakened for that one seat.
+
+**Expert lenses (optional element, when ON):** every seat gets a distinct per-seat brief, so there is no shared-prompt wave — launch **all** legs as concurrent solo runs (`_tmp-briefing-lens-<slug>.md`, one per seat), using the lens templates and panel-scoping rules in `SEAT-BRIEFS.md § Expert lens briefs`. The lens↔model assignment is random and lives only in the private label map — no reviewer learns the other seats' lenses. Same structured-output contract and validation. Record `role: "lens:<slug>"` on each `runStats` entry. Two standing consequences, both disclosed in `report.md`: Stage-2 anonymity is weakened (each judge can spot its own lens-flavored review), and the Stage-2 tally runs `--no-ledger` (lens reviews are not comparable to standard reviews and must not feed cross-run reliability stats). Wave-degrade rules apply to these solos exactly as to fanout legs.
+
 **Cowork / no-Bash environments:** use the MCP tools instead — `amicus_fanout` (briefing via
-file) returns `{waveId, taskIds[]}` immediately; poll `amicus_status`, then `amicus_read` each
-leg. The council's briefings are always self-contained (`--no-context`), so MCP transport is
-equivalent.
+file) returns `{waveId, taskIds[]}` immediately. Preferred: call `amicus_wait` with the waveId —
+one blocking call per wave; re-call it while it returns `timedOut: true`. Fallback: poll
+`amicus_status`. Either way, `amicus_read` each leg when done. The council's briefings are always
+self-contained (`--no-context`), so MCP transport is equivalent.
 
 **Required structured output from every model.** Instruct each council model to produce:
 
@@ -165,6 +190,8 @@ equivalent.
 
 Instruct models to emit the structured JSON verbatim after the prose, without preamble, so it parses cleanly.
 
+**Every Stage-1 briefing — standard seats included — must contain the standard anti-sycophancy clause from `SEAT-BRIEFS.md` verbatim** (do not soften, lead with the most severe finding, no praise cushions, no padding — an empty severity category is a valid result). This is briefing hygiene, not an optional element.
+
 Save each leg's full output (prose + findings block) to the run folder as `review-<model>.md`
 (one file per reviewer) before moving on.
 
@@ -231,6 +258,8 @@ FINAL RANKING:
 
 **Task B — Adjudicate findings.** For every finding in the bundle, state: `agree | dispute | neutral` plus one-line reason. Reference each finding as **review-label + finding-id** — for example, `A2` means Review A's 2nd finding, `B1` means Review B's 1st finding. An "I missed this — it's valid" counts as `agree`.
 
+**When critic seat or expert lenses are ON:** the bundle and judging instructions must not mention seats, lenses, or briefs — judges rank and adjudicate on accuracy and insight only. The element briefs are Stage-1 information; leaking them into Stage 2 tells every judge which review is which.
+
 As each judge's ranking + adjudication response returns, collect it (the raw per-judge responses are working intermediates, not separate run-folder artifacts). Once all are in, **assemble the de-anonymized tally input** and then call `amicus council tally`:
 
 **Stage-2 → tally assembly recipe (Claude's work before calling `tally`):**
@@ -250,12 +279,34 @@ Then call, saving the printed `record` to `<run-folder>/tally.json` (Stage 5's `
 amicus council tally <run-folder>/tally-input.json --json > <run-folder>/tally.json
 ```
 
+**Ledger flags for optional elements:** when **expert lenses** are ON, always pass `--no-ledger` — lens runs never feed cross-run reliability stats. When **debate mode** is ON, this Stage-2 tally is *provisional* — pass `--no-ledger` here; the final, ledger-recorded tally happens at the end of Stage 2.5 (the critic seat and Claude-in-the-council change nothing about ledger handling).
+
 **Windows PowerShell 5.1 caveat:** that `>` redirect writes UTF-16 under legacy Windows PowerShell 5.1 (fine on pwsh 7+ or bash), which corrupts `tally.json` for Stage 5's `amicus council verdict` and surfaces as a confusing `BAD_ARGS` there instead of here — on 5.1 pipe through `| Out-File -Encoding utf8` (or run under pwsh 7+) instead of a bare `>`.
 
 The output `record` carries the deterministic tiers (Disputed / Confirmed / Contested / Singleton), `confidence` (`solid` | `thin`), both street-cred numbers (`withSelf` and `peersOnly`), the validated `runStats`, and `tierCounts`. **Claude may override a `thin`-confidence tier at the margins** before Stage 4 — record the override in `tierOverride: {from, to, reason}`; the matrix and `verdict.json` surface it. De-anonymize and write the tally results to `crossreview-matrix.md` — the adjudication grid plus the street-cred table. This data feeds Stage 3 (chair briefing) and is never re-anonymized or forwarded to any council model.
 
 ---
 
+### Stage 2.5 — Rebuttal round ("debate mode", optional element — skip this entire stage when OFF)
+
+One structured challenge round on the findings the bench did not settle: every **Contested** and **Disputed** finding goes back to its raiser to defend, amend, or withdraw; the judges that disputed it re-vote; then the final tally. **Exactly ONE round, ever** — never iterate further; whatever remains unsettled after the re-vote keeps its final tier. Briefing templates are in `SEAT-BRIEFS.md § Rebuttal-round templates`; every rebuttal briefing opens with the no-tools preamble, same as Stage 2.
+
+The Stage-2 tally above ran `--no-ledger` (provisional). If it produced **zero Contested + Disputed findings**, skip the rebuttal waves entirely: re-run the tally on the unchanged input *without* `--no-ledger` to record it, note "debate mode: nothing to debate" for `report.md`, and proceed to Stage 3.
+
+**1. Defense mini-wave.** For each raiser with ≥ 1 Contested/Disputed finding, write `_tmp-rebuttal-<label>.md`: its findings (run-global ids and claims), each with the peers' dispute reasons — anonymized, no judge identities. Launch one concurrent solo run per raiser (same flags and budget-gate handling as the Stage-1 solos). Parse each response line: `<id>: DEFEND — …` | `<id>: AMEND — <replacement claim>` | `<id>: WITHDRAW`. A missing or unparseable line = the original claim stands undefended (original verdicts carry).
+
+**2. Re-vote mini-wave.** Build ONE shared `_tmp-revote-bundle.md` holding every defended or amended finding plus its (anonymous) defense. Send it as a single fanout wave to the judges that disputed at least one of those findings — judges that never disputed sit this round out. Parse verdict lines `<id>: agree | dispute | neutral — <reason>`; a judge's missing line = its original verdict stands.
+
+**3. Final tally.** Re-assemble the tally input: re-vote verdicts replace those judges' original adjudications on those findings; AMENDED claims replace the originals (`id`, `raiser`, and `severity` unchanged); WITHDRAWN findings **stay in `findings[]`** (they were raised) and take whatever tier the final cascade assigns. Run `amicus council tally` **without** `--no-ledger` (unless expert lenses are also ON — lens runs never ledger) and save this record as the run's `tally.json`. This final record — not the provisional one — is what Stages 3–5 consume; the chair packet and `crossreview-matrix.md` are built from it, with verdict changes from the re-vote called out before/after.
+
+**Withdrawals downstream:** WITHDRAWN findings are auto-recorded in `decisions.json` as `{"id": …, "decision": "denied"}` — never presented for a user decision in Stage 4 — and listed in `report.md` under "Withdrawn by raiser (debate mode)".
+
+**Degrade rules:** a dead defense leg → all of that raiser's contested findings stand undefended. A dead re-vote leg → that judge's original verdicts carry. Never re-run the round.
+
+**Cost/shape:** adds up to 2 short waves (≤ N defense solos + 1 re-vote fanout), disclosed at Stage 0. If the actual rebuttal surface turns out much larger than estimated (many contested findings), say so before launching the mini-waves.
+
+---
+
 ### Stage 3 — Council-chair synthesis
 
 A designated **non-Claude** chair synthesizes the verdict across all reviews, rankings, and adjudications. The chair produces an independent verdict that Claude then presents — Claude does not paraphrase, edit, or re-synthesize it.
@@ -290,6 +341,8 @@ Instruct the chair to write a **synthesized verdict** that:
 - Distinguishes findings the bench broadly endorsed from contested or singleton claims
 - Arrives at an overall assessment of the artifact
 
+**Chair verdict scale (optional element, when ON):** append the addendum from `SEAT-BRIEFS.md § Chair verdict-scale addendum` to the chair packet — the chair must close with 3–5 **hard questions** the artifact's author probably hasn't asked themselves, then a final parseable line: `VERDICT: Ship it | Fix these first | Fundamental rethink`. Surface that line verbatim at the top of `report.md` and in the inline chat presentation. When debate mode is also ON, the chair packet is built from the *final* (post-rebuttal) tally and includes the defense/re-vote outcomes.
+
 Save the chair's output to the run folder as `verdict.md`.
 
 ---
@@ -300,6 +353,8 @@ All findings from the bundle are sorted into tiers based on the **peer-confidenc
 
 **Scale-down:** In a 1-model run, Stage 2 was skipped — there is no peer-confidence data, so present every finding individually for decision (no tiers). In a 2-model run, the Confirmed tier rests on thin cross-review (one ranker per review, per Stage 0) — say so when presenting it.
 
+**Debate mode:** the tiers below come from the *final* (post-rebuttal) tally. Findings WITHDRAWN by their raiser in Stage 2.5 are already recorded as `denied` — do not present them for decision; note them as withdrawn when walking the tiers.
+
 **Consensus tier — Confirmed findings** (≥ 2 peer agreements, agrees dominate)
 
 - Present the full list in one block: id, claim, severity, and which models raised / endorsed it.
@@ -340,7 +395,12 @@ Do not advance to Stage 5 until every finding in both tiers has a recorded decis
 - `verdict.md` (already saved in Stage 3)
 - `verdict.json` — write by running `amicus council verdict <run-folder>/tally.json --decisions <run-folder>/decisions.json -o <run-folder>/verdict.json` (a thin CLI wrapper over `buildVerdict(record, decisions)` + `writeVerdictAtomic`, `src/council/verdict.js`). `<run-folder>/tally.json` is the `record` saved from the Stage-2 `amicus council tally` call. `<run-folder>/decisions.json` is a **JSON array**, one object per finding: `{id, decision, applied?, duplicateOf?, tierOverride?}` — `id` is the run-global label id (e.g. `A1`); `decision` is the Stage-4 outcome (accepted / denied / modified / deferred); `applied` (optional bool) marks whether the accepted change was actually applied to the artifact in Stage 5; `duplicateOf` (optional) links to another finding's id when Claude identified a duplicate; `tierOverride` (optional) carries any `{from, to, reason}` override recorded in Stage 2. Save this array to `<run-folder>/decisions.json` first, then run the command — it parses the tally record and the decisions file, calls `buildVerdict`, and writes the schema-stamped machine-readable record to the run folder via the same atomic tmp+rename convention the function always used.
 - `report.md` — the chair's synthesis + the full Stage-4 decision log + a summary of what was
-  applied (+ the "How Claude's review fared" readout when "Claude in the council" is on) + a
+  applied (+ the "How Claude's review fared" readout when "Claude in the council" is on) + an
+  **Optional elements** section whenever any element was ON: which elements ran; the chair's
+  `VERDICT:` line verbatim at the top of the report (chair verdict scale); the "Withdrawn by
+  raiser (debate mode)" list and re-vote verdict changes (debate mode); and the standing
+  disclosures — critic self-identification in cross-review (critic seat), weakened anonymity +
+  non-comparable street-cred + `--no-ledger` (expert lenses) + a
   **run-stats table**: one row per model call — **stage** (which stage you launched the call for)
   plus **model, status, durationMs, and cost** read from the wave/run JSON `usage`
   block. Cost is `usage.cost.amount` (USD); mark it with its `usage.cost.source`
@@ -376,7 +436,7 @@ The `MODEL-NOTES.md` **next to this file** is your machine-local run ledger: npm
 
 Draft new or updated entries for the per-model sections of `MODEL-NOTES.md` that capture what was learned.
 
-**Ledger auto-append (automatic — no approval required).** Running `amicus council tally` (the Stage-2 finalize call) appends one row per (run × model) to the append-only `council-ledger.jsonl` under `getConfigDir()` — no separate step is needed. Pass `--no-ledger` to compute a tally record *without* recording it (e.g. a re-tally that shouldn't double-count). The run summary shows the appended row. This is a deterministic, content-free model-level record (no finding text, no claim strings, no artifact body content). The quantitative reviewer-reliability data in `MODEL-NOTES.md` is now sourced entirely from `amicus council stats` (which aggregates the ledger) — **do not hand-edit reliability numbers in MODEL-NOTES**.
+**Ledger auto-append (automatic — no approval required).** Running `amicus council tally` (the finalize call — Stage 2, or the Stage-2.5 final tally when debate mode is on; skipped entirely on expert-lens runs, which always pass `--no-ledger`) appends one row per (run × model) to the append-only `council-ledger.jsonl` under `getConfigDir()` — no separate step is needed. Pass `--no-ledger` to compute a tally record *without* recording it (e.g. a re-tally that shouldn't double-count). The run summary shows the appended row. This is a deterministic, content-free model-level record (no finding text, no claim strings, no artifact body content). The quantitative reviewer-reliability data in `MODEL-NOTES.md` is now sourced entirely from `amicus council stats` (which aggregates the ledger) — **do not hand-edit reliability numbers in MODEL-NOTES**.
 
 **Compose the proposed MODEL-NOTES diff.** Combine the run-lessons updates and the reviewer-reliability table updates into a single proposed diff (old → new for every changed section). **Write the full diff to a file in the run folder** — `_tmp-proposed-model-notes-update.md` — so the user can open and review it before deciding. Presenting the diff as chat text alone is **not sufficient**: an approval dialog can hide the chat transcript, so the user may be asked to decide on a diff they never saw.
 
@@ -475,13 +535,15 @@ Always **rank recommendations by fit**, state the trade-off for each option, and
   - `report.md` — Claude-authored; full contract defined once in *Stage 5 → Run-folder artifacts* above (chair's synthesis + Stage-4 decision log + run-stats table).
   - `report.html` — a **separate, deterministic** artifact generated by the `amicus council report <verdict.json> --html` renderer directly from `verdict.json` (no chair prose, no decision-log narrative — see Stage 5's *Renderer* note); the default artifact to share.
 - Reviewed copy: `<stem>-reviewed.<ext>`, next to the source.
-- Temp working files (`_tmp-*.md`: extracts, stage briefings, red-team brief, bundle, chair packet, proposed
-  MODEL-NOTES diff) live in the run folder and are cleaned up at the end of the run — the proposed-diff file
-  only after the Stage-6 approval decision is resolved.
+- Temp working files (`_tmp-*.md`: extracts, stage briefings, red-team brief, critic/lens seat briefs
+  (`_tmp-briefing-critic.md`, `_tmp-briefing-lens-<slug>.md`), rebuttal briefs (`_tmp-rebuttal-<label>.md`,
+  `_tmp-revote-bundle.md`), bundle, chair packet, proposed MODEL-NOTES diff) live in the run folder and are
+  cleaned up at the end of the run — the proposed-diff file only after the Stage-6 approval decision is resolved.
 
 ---
 
 ## Files
 
 - `MODEL-NOTES.md` — operating rules, per-model qualitative quirks, cost guardrail, and structural-conformance notes. **Read it before Stage 0 (council selection and launch); update qualitative notes (with approval) in Stage 6.** Quantitative reliability data (runs, avg street-cred, confirm-rate, fact-error rate) comes from `amicus council stats`, not this file. This copy is machine-local (never overwritten on update); the shipped seed lives in the amicus repo and absorbs durable lessons at release time.
-- `COUNCIL-DESIGN.md` — the design spec this skill implements (v3 + WS-3). Consult it if a mechanics question arises that the skill prose does not resolve.
+- `SEAT-BRIEFS.md` — briefing boilerplate for the optional council elements (critic seat, expert lenses, rebuttal round, chair verdict scale) plus the standard anti-sycophancy clause every Stage-1 briefing carries. **Read it whenever any element is toggled on at Stage 0** (the anti-sycophancy clause applies to every run).
+- `COUNCIL-DESIGN.md` — the design spec this skill implements (v3 + WS-3; §12 covers the optional council elements). Consult it if a mechanics question arises that the skill prose does not resolve.

package/skills/sidecar/SKILL.md

@@ -45,7 +45,7 @@ These rules are mandatory for every amicus invocation in this skill:
 5. **When the user asks to query MULTIPLE LLMs simultaneously** (e.g., "ask Gemini AND ChatGPT", "compare Gemini vs GPT"), ALWAYS use `--no-ui` (headless) for all of them unless the user explicitly requests interactive. Opening multiple Electron windows at once is disruptive. Launch them all in parallel with `run_in_background: true`.
 6. **When the SAME prompt should go to N models, use `amicus fanout --models "a,b,c" --prompt-file <path> --json`** (one headless wave, one JSON result) instead of N separate start calls. Different prompts per model → separate parallel `amicus start --no-ui` calls.
 7. **For a SINGLE-model sidecar, DEFAULT to interactive** — omit `--no-ui` so the Electron UI opens and the user can watch, converse, and click Fold. Use `--no-ui` for a single model only when the user asks for headless/autonomous, or for unattended bulk automation. Interactive launches still use `run_in_background: true`.
-8. **If `amicus` is not on PATH** (typical for plugin-only installs), run every command in this skill as `npx -y amicus@latest <args>` (e.g. `npx -y amicus@latest start --model gemini --prompt "..."`), or use the MCP tools (`amicus_start`, `amicus_status`, `amicus_read`, …) instead. Do not conclude the tool is broken because `amicus` is not found.
+8. **If `amicus` is not on PATH** (typical for plugin-only installs), run every command in this skill as `npx -y amicus@latest <args>` (e.g. `npx -y amicus@latest start --model gemini --prompt "..."`), or use the MCP tools (`amicus_start`, `amicus_wait`, `amicus_status`, `amicus_read`, …) instead. Do not conclude the tool is broken because `amicus` is not found.
 
 ## Installation
 
@@ -65,7 +65,7 @@ amicus --version
 
 ### MCP Server (Auto-Registered)
 
-On install, an MCP server is auto-registered for Claude Cowork and Claude Desktop. If you're in an MCP-enabled environment, you can use `amicus_start`, `amicus_status`, `amicus_read`, and other MCP tools directly instead of CLI commands. Call `amicus_guide` for detailed usage instructions.
+On install, an MCP server is auto-registered for Claude Cowork and Claude Desktop. If you're in an MCP-enabled environment, you can use `amicus_start`, `amicus_wait`, `amicus_status`, `amicus_read`, and other MCP tools directly instead of CLI commands. Call `amicus_guide` for detailed usage instructions.
 
 ---
 
@@ -177,7 +177,7 @@ amicus start --model anthropic/<model-name> --prompt "..."
 
 ### Agent Selection Guidelines
 
-**Chat mode (default)** — no `--agent` flag needed. Reads are auto-approved, writes and bash commands require user permission in the Electron UI:
+**Chat mode (interactive default)** — no `--agent` flag needed. Reads are auto-approved, writes and bash commands require user permission in the Electron UI:
 ```bash
 # Default — good for questions, analysis, and guided work
 amicus start --model gemini --prompt "Analyze the auth flow and suggest improvements"
@@ -199,7 +199,7 @@ amicus start --model gemini --prompt "Implement the login feature" --agent Build
 
 | Mode | Use When |
 |------|----------|
-| **Chat** (default) | Questions, analysis, guided exploration — you control what gets written |
+| **Chat** (interactive default) | Questions, analysis, guided exploration — you control what gets written |
 | **Plan** | Comprehensive read-only analysis where no changes should happen |
 | **Build** | Offloading implementation tasks where full autonomy is desired |
 
@@ -250,14 +250,17 @@ amicus start \
 - `--prompt-file <path>`: Read the prompt/briefing from a UTF-8 file (mutually exclusive with
   `--prompt`). Use for long or multi-line briefings.
 - `--json`: With `--no-ui`, emit the run result as one stable JSON document on stdout
-  (`schemaVersion: 1`; the `summary` field is the model's output).
+  (`schemaVersion: 2`; the `summary` field is the model's output).
 - `--no-validate-model`: Skip the model-catalog pre-flight check (validation is on by default).
-- `--agent <agent>`: Agent mode (controls tool permissions). If omitted, defaults to **Chat**.
+- `--agent <agent>`: Agent mode (controls tool permissions). If omitted, defaults to
+  **Chat** in interactive mode and **Build** in headless (`--no-ui`) mode — `chat`
+  stalls without user interaction, so headless runs need an agent that doesn't wait
+  on write/bash approval.
 
   **Primary Agents (for `amicus start`):**
-  - `Chat` **(default)**: Reads auto-approved, writes/bash require user permission
+  - `Chat` **(interactive default)**: Reads auto-approved, writes/bash require user permission
   - `Plan`: Read-only mode - no file modifications possible
-  - `Build`: Full tool access - all operations auto-approved
+  - `Build` **(headless default)**: Full tool access - all operations auto-approved
 
   **Custom Agents:**
   Custom agents defined in `~/.config/opencode/agents/` or `.opencode/agents/` are passed through directly.
@@ -573,16 +576,16 @@ Amicus uses OpenCode's agent framework with three primary modes:
 
 | Agent | Reads | Writes/Edits | Bash | Default |
 |-------|-------|-------------|------|---------|
-| **Chat** | auto | asks permission | asks permission | Yes |
+| **Chat** | auto | asks permission | asks permission | Interactive |
 | **Plan** | auto | denied | denied | No |
-| **Build** | auto | auto | auto | No |
+| **Build** | auto | auto | auto | Headless |
 
-#### Chat Agent (Default)
+#### Chat Agent (Interactive Default)
 
-Conversational mode — reads are auto-approved, writes and bash commands prompt for user permission in the UI. This is the default when no `--agent` flag is provided.
+Conversational mode — reads are auto-approved, writes and bash commands prompt for user permission in the UI. This is the default when no `--agent` flag is provided **in interactive mode**; headless (`--no-ui`) runs default to Build instead (see the Headless section below).
 
 ```bash
-# These are equivalent — Chat is the default
+# These are equivalent — Chat is the interactive default
 amicus start --model gemini --prompt "Analyze the auth flow"
 amicus start --model gemini --prompt "Analyze the auth flow" --agent Chat
 ```
@@ -781,7 +784,7 @@ If a relevant sidecar exists:
 ### Example 1: Interactive Debugging (Chat Mode - Default)
 
 ```bash
-# Default Chat mode — can read freely, asks before writing
+# Chat mode (interactive default) — can read freely, asks before writing
 amicus start \
   --model gpt \
   --session-id "$(ls -t ~/.claude/projects/-Users-john-myproject/*.jsonl | head -1 | xargs basename .jsonl)" \