packages/skills-catalog/skills/(decision-making)/the-jury/SKILL.md
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.
npx skillsauth add tech-leads-club/agent-skills the-juryInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
Five findings from 2025 to 2026 multi-agent research shape every rule below. Keep them in mind; do not recite them to the user.
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.
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:
Read references/juror-archetypes.md now to choose the panel. Rules:
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.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 in one context, but you MUST generate every Round 1 position before revealing any position to any juror. Blindness is non-negotiable; it is the anti-anchoring gate.
Each juror returns, in a compact structured block:
Record all Round 1 positions and confidences. These are the independent votes; you will need them again in Phase 4.
Anonymize Round 1: strip every persona and identity label and relabel positions neutrally (Position 1, Position 2, ...). Identity leakage causes same-backbone favoritism and sycophancy, so jurors must not know who said what. Collate the anonymized positions and send them back to each juror using the Round 2 prompt template.
In Round 2 each juror must:
Adaptive stop: after Round 2, if positions are stable (no juror made a material change), STOP deliberating and go to Phase 4. Run a single additional round ONLY if there was a large genuine shift AND the panel is still split on the merits. Never exceed 2 deliberation rounds regardless.
Record final positions, final confidences, and each flip's cited reason.
Compute the verdict deterministically. If code execution is available, run the tally script:
python scripts/tally.py --input jury.json
where jury.json holds each juror's initial_choice, initial_confidence, final_choice, final_confidence, flip_reason, evidence_grade, and a panel-level diversity note. The script returns the confidence-weighted scores, flip and bandwagon flags, the homogeneity caveat, and a recommended verdict. See the header of scripts/tally.py for the exact JSON shape.
If code execution is not available, apply the same cascade by hand:
The verdict is mandatory. At worst you return LOW or PIVOT confidence with the least-bad option plus a test, never "no decision".
Output ONLY the verdict block from the next section, in the user's language. No preamble, no transcript of the deliberation, no closing pleasantries. If the user later asks to see the reasoning, then share the per-juror positions and the tally.
The verdict follows an ADHD-friendly contract: decision first, numbered reasons, no filler, one concrete next action. Keep it tight.
VERDICT: <the decision, one actionable line>
Confidence: HIGH | MEDIUM | LOW | PIVOT
Why:
1. <reason, grounded in the rubric and evidence>
2. ...
(max 5, ranked; cut the rest)
Dissent: <the strongest minority position, preserved in one line; "none" only if genuinely unanimous>
Riskiest assumption: <the single thing that, if false, breaks the verdict>
Test: <one concrete experiment or check to validate that assumption>
Next: <one action the user can take now, under a few minutes to start>
Confidence rubric:
User says: "Compaction is thrashing our write path. Convene a jury: keep the LSM store and tune it, or migrate hot tables to the new engine this quarter?"
Actions:
Verdict:
VERDICT: Tune the current engine this quarter; do not migrate yet.
Confidence: MEDIUM
Why:
1. Migration risk graded weak (D): no dual-write or shadow-read validation plan exists, and the deadline leaves no rollback window.
2. Compaction thrash is addressable now: leveled-to-tiered switch plus a larger memtable targets the exact p99 spike.
3. Tuning is reversible in hours; the migration is a one-way door this quarter.
4. Team of 4 cannot own two write paths during the freeze.
Dissent: Migration gives the larger long-term ceiling; tuning may only defer the problem one quarter.
Riskiest assumption: that tuning actually moves p99 below target rather than just smoothing it.
Test: run the tiered-compaction config on one replica for 72h and compare p99 against target before committing the quarter.
Next: clone the config to a canary replica and enable tiered compaction.
User says: "Painel para decidir: construir nosso conector de billing ou comprar o SaaS X?"
Actions:
Verdict (emitted in Portuguese, the user's language):
VEREDITO: Comprar o SaaS X agora; reavaliar build em 12 meses.
Confianca: MEDIUM
Por que:
1. Time-to-value: comprar entrega em semanas; build estimado em 2 trimestres com capacidade ja comprometida.
2. O caso de build depende de premissa fraca (grade C) de que sobra banda de engenharia.
3. Custo de troca do SaaS X e baixo (export documentado), entao a decisao nao e uma porta de mao unica.
Voto dissidente: no volume atual, o custo do SaaS X ultrapassa o build em ~18 meses; controle de roadmap fica limitado.
Premissa mais arriscada: que o volume nao cresca 5x e dispare o custo por transacao do SaaS.
Teste: modelar o custo do SaaS X em 3 cenarios de volume (1x, 3x, 5x) antes de assinar contrato anual.
Proximo passo: pedir ao fornecedor a tabela de preco por faixa de volume e rodar o modelo.
references/juror-archetypes.md: the persona and role library organized by domain, orthogonality guidance, and panel-size guidance. Read during Phase 1, every time.references/deliberation-craft.md: the six critical lenses (the Fool's rigor), the anti-sycophancy and anti-anchoring details, the Round 1 and Round 2 subagent prompt templates, a compact cognitive-bias checklist, and the evidence base. Read before Phase 1 (to assign lenses) and keep open through Phase 3 (for the prompt templates).scripts/tally.py: deterministic confidence-weighted aggregation plus flip, bandwagon, and homogeneity checks. Run in Phase 4 when code execution is available; otherwise follow the by-hand cascade in Phase 4.Cause: low diversity, or an easy question. Check the panel: same viewpoints repeated? If so, the consensus is weak evidence (homogeneity cap applies). If diversity was real and the devil's advocate genuinely tried and failed to break the position, HIGH confidence is warranted. Either way, still emit the verdict; do not force artificial disagreement.
Cause: sycophancy or anchoring failure. Enforce the flip-must-cite-a-reason rule and stop at the 2-round cap. If the flips are unjustified, mark SUSPECT and fall back to the independent Round 1 aggregate at LOW confidence.
Cause: genuinely balanced options. Do not abstain and do not coin-flip. Decide on the merits per the rubric: higher evidence grade and better survival against the devil's advocate wins. Record the closeness as dissent and lower the confidence.
Cause: role fidelity slip. Re-prompt that juror to pick the single best option under the current evidence and to put its caveats into the assumptions field, not the position field. A jury delivers positions, not essays.
tools
Feature planning and implementation with 4 adaptive phases (Specify, Design, Tasks, Execute). Auto-sizes depth by complexity. Writes testable requirements in EARS notation, atomic tasks, atomic Conventional Commits, and requirement traceability. Ships deterministic Python validation scripts so structural gates are enforced by code, not memory. Features an independent Verifier (author != verifier, evidence-or-zero), a discrimination sensor, a decision log (STATE.md), a test-coverage matrix, and a self-improving lessons layer. Stack-agnostic and tool-agnostic. Use when (1) planning features, (2) implementing with verification and atomic commits, (3) validating an implementation against a spec. Triggers on "specify feature", "discuss feature", "design", "tasks", "implement", "validate", "verify work", "UAT", "record decision", "pause work", "resume work". Do NOT use for pure architecture decomposition analysis or standalone technical design documents.
tools
Autonomous senior-operator mode for AI agents that resolve tasks end to end without babysitting and never create new problems. The agent verifies every claim against real evidence (web search dated to the current month and year, the codebase, and available tools, MCPs, and CLIs); it never guesses, never fakes confidence, and never claims something is done without proof. It stays silent and keeps working, interrupting the user only on three stops, namely a destructive or irreversible action, a dead-end with no evidence after exhausting sources, or genuine ambiguity that changes the outcome. Output is short, literal, and human. Use when the user says "not-your-babysitter", "nanny mode", "work autonomously", "stop babysitting", or "no hand-holding", or wants an agent that solves problems on its own, especially hands-on engineering and operational tasks. Do not use when the user explicitly wants a tutorial, a verbose walkthrough, or open-ended brainstorming.
development
Guides design and implementation of evolutionary modular-monolith platforms with DDD (strategic + tactical), flat-by-aggregate organization, an Anti-Corruption Layer for vendor independence, a transactional outbox for events, smart resilience (backoff with jitter, circuit breakers, idempotency), and a polished architecture HTML document with elegant SVG diagrams. Use when designing a platform or backend, defining bounded contexts, organizing modules and folders, choosing monolith vs microservices, decoupling from an external service (ERP, storage, AI), making calls resilient, adding real-time push, picking a 2026 TypeScript stack (Nx, NestJS, React), or producing an architecture document or diagram. Also triggers on 'modular monolith', 'bounded contexts', 'flat-by-aggregate', 'ports and adapters', 'architecture diagram'. Do NOT use for simple CRUD, NestJS-only deep implementation (use nestjs-modular-monolith), or pure domain-model review (use tactical-ddd).
tools
Reviews a GitHub pull request and posts inline comments plus one consolidated summary, adapting to any codebase by discovering the project's own test runner, requirement specs, and architecture conventions before running six specialized review agents in parallel. Stack-agnostic across language and framework; targets GitHub PRs via the gh CLI. Use when the user says "review PR 128", "review this PR", "code review this PR", or "check this pull request". Do NOT use for creating PRs or responding to review comments (use gh-address-comments), or debugging failing CI checks (use gh-fix-ci).