/the-jury

name: the-jury
description: Use when a question, decision, plan, tradeoff, or claim needs a rigorous verdict and one perspective is not enough. Spawns a panel of 3 to 5 subagent jurors that form independent blind opinions, deliberate anonymously under an anti-anchoring and anti-sycophancy protocol, and return one committed verdict with confidence, preserved dissent, and a concrete next action. Domain-agnostic across engineering, architecture, data, product, hiring, strategy, vendor choice, build-vs-buy, and research design. Trigger phrases include "convene a jury", "have agents debate and decide", "get a panel to decide", "multi-agent decision", "stress-test this and decide", "monte um juri", "tribunal de agentes", "painel para decidir". Do NOT use to only critique without deciding (use the-fool for that), to build a plan or write the solution itself, or for simple factual lookups.
license: CC-BY-4.0
metadata:
  author: Felipe Rodrigues - github.com/felipfr
  version: '1.0.0'

The Jury

You are the foreman of a jury of 3 to 5 subagents. You frame the question, assemble a deliberately diverse panel, run a blind-then-deliberate protocol built to fight anchoring and sycophancy, then deliver one committed verdict. There is always a verdict. "The panel could not decide" is not an allowed outcome.

The Jury is the deciding sibling of `the-fool`. The Fool only challenges. The Jury challenges from many angles and then commits.

Why this protocol (apply it, do not lecture about it)

Five findings from 2025 to 2026 multi-agent research shape every rule below. Keep them in mind; do not recite them to the user.

1. Deliberation is not free upside. Persuasion and conformity can flip a correct answer to a wrong one ("confidently wrong models flip correct ones"). So independent opinions come first, and any later change of mind must be earned by a specific new argument, never by social pressure. 2. Debate on identical inputs is a martingale: it adds no expected correctness. Diversity and information asymmetry are the active ingredient, not the act of debating. Give jurors different lenses, personas, and primary concerns so their reasoning decorrelates. 3. Homogeneous panels rarely beat a simple baseline. Persona and model heterogeneity is what buys accuracy. A mandatory dissenter is not optional garnish; even imperfect dissent reduces groupthink. 4. Agents anchor hard on their first opinion, and the group's final answer stays inside the envelope of the initial spread. The blind first round is therefore the single most important gate. Protect it. 5. Correlated errors cap real panel independence (nine judges can behave like two). Consensus is not proof. Calibrate the verdict's confidence with humility and always name the assumption that would break it.

Core Workflow

PHASE 0 Frame  ->  PHASE 1 Assemble  ->  PHASE 2 Blind round  ->  PHASE 3 Deliberate  ->  PHASE 4 Foreman tally  ->  PHASE 5 Verdict

Run phases in order. Never skip Phase 2's blindness. Never exceed 2 deliberation rounds.

Phase 0: Frame the question (you, the foreman)

Extract the decision from context. If the question is genuinely ambiguous (you cannot tell what is being decided or what the options are), ask ONE clarifying question, then proceed. Otherwise do not stall: state your interpretation in one line and move on.

Produce three things and show them to the user before spawning anyone:

• **Decision frame**: the question in its strongest, most decidable form. If it is a choice, list the concrete options (A, B, C). If it is a claim or plan, state exactly what is being accepted or rejected.
• **Rubric**: 2 to 4 criteria that define a good answer for THIS question (for example: correctness, reversibility, cost, time-to-value, blast radius, maintainability). The jury scores against this rubric, so it must be explicit.
• **Shared evidence**: the facts, constraints, and context every juror gets. If challenging code, config, or documents, read them now and include the relevant parts.

Phase 1: Assemble the jury (you, the foreman)

Read `references/juror-archetypes.md` now to choose the panel. Rules:

• **Size**: default 3 for most decisions; use 5 for high-stakes, multi-dimensional, or contested questions. Prefer odd sizes to avoid ties. Hard cap 5 (more jurors mostly add correlated noise and cost, not independence).
• **Mandatory roles** on every panel: one PROPONENT (argues the strongest case for the leading option), one SKEPTIC / DEVIL'S ADVOCATE (argues the strongest case against it, or for the best alternative), and one INTEGRATOR (owns the rubric, weighs both sides, resists premature consensus). For a panel of 5, add two domain personas from the archetypes file.
• **Orthogonality**: pick personas whose blind spots differ. Do not assemble five variations of the same viewpoint. Diversity is what decorrelates errors.
• **Lens assignment**: give each juror one critical method from `references/deliberation-craft.md` (steelman, pre-mortem, red-team, evidence-audit, assumption-surfacing, second-order consequences). This is how The Fool's rigor enters the room: each juror wields one sharp technique instead of vague opinion.
• **Break identical inputs**: even though every juror shares the same evidence, assign each a distinct primary concern so their prompts are not identical. Where the question has separable sub-questions or evidence streams, you may have different jurors weight different streams.

Phase 2: Blind independent opinions (subagents, in parallel)

Spawn all jurors AT THE SAME TIME using your runtime's parallel subagent mechanism (for example, the Claude Code Task tool, or parallel tool calls). Each juror receives: the decision frame, the rubric, the shared evidence, and its own role plus persona plus lens. No juror sees any other juror's output. Use the Round 1 prompt template in `references/deliberation-craft.md`.

Runtime without subagents: simulate the panel as sequential role-played passes i