A skill your agent uses when a question, decision, plan, tradeoff, or claim needs a rigorous verdict and one perspective is not enough.

CC-BY-4.0Auto-check passedAgent Workflows

Install The Jury

skills CLI
$ npx skills add tech-leads-club/agent-skills --skill the-jury -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install tech-leads-club/agent-skills the-jury --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/tech-leads-club/agent-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/'packages/skills-catalog/skills/(decision-making)/the-jury' .claude/skills/the-jury && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
the-jury
GitHub stars
7k
Token cost
~4.5k tokens
SKILL.md length
2,194 words
Files
4 (incl. scripts, references)
Skills in repo
74
Repo updated
First seen
Licence
CC-BY-4.0

At a glance

A skill your agent uses when a question, decision, plan, tradeoff, or claim needs a rigorous verdict and one perspective is not enough.

  • Works in 6 steps: Frame the question (you, the foreman) → Assemble the jury (you, the foreman) → Blind independent opinions (subagents,… → …
  • Claim needs a rigorous verdict and one perspective is not enough
  • SKILL.md covers Why this protocol (apply it,…, Core Workflow, Verdict format (mandatory shape) and Constraints, plus 3 more sections
  • Runs Python scripts from its folder; calls python

What it does

The Jury is an agent skill from tech-leads-club/agent-skills. 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…

Its SKILL.md is about 4.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including scripts and reference files (for example `references/deliberation-craft.md`, `references/juror-archetypes.md` and `scripts/tally.py`).

It sits in Agent Workflows, covering Subagents and Load testing. The repository describes itself as: The secure, validated skill registry for professional AI coding agents. Extend Antigravity, Claude Code, Cursor, Copilot and more with absolute confidence. The licence is CC-BY-4.0.

When your agent uses it

  • Claim needs a rigorous verdict and one perspective is not enough
  • Phrases include convene a jury
  • Have agents debate and decide
  • Get a panel to decide

Example prompts

  • “convene a jury”
  • “have agents debate and decide”
  • “get a panel to decide”
  • “/the-jury”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Frame the question (you, the foreman)
  2. Assemble the jury (you, the foreman)
  3. Blind independent opinions (subagents, in parallel)
  4. Anonymized deliberation (subagents)
  5. Foreman tally and synthesis (you, the foreman)
  6. Emit the verdict

What it can do on your machine

Read from SKILL.md and the folder at commit 6df68d5. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • python

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

The Jury loads about 4.5k tokens when it runs, and up to ~8.6k if it reads all its reference files. Until then it costs about 219 tokens; SKILL.md has 2,194 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~219
When it runs · the whole SKILL.md, loaded when a task matches
~4.5k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~8.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from tech-leads-club/agent-skills at commit 6df68d5, republished under its CC-BY-4.0 licence (© tech-leads-club). 2,194 words, ~4,506 tokens.

Download SKILL.mdSave it as .claude/skills/the-jury/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
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
metadata.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 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:

  • Position: the option it picks, or its stance on the claim. It must commit; "it depends" is not a position.
  • Top arguments: 2 to 4 concrete, grounded points using its lens. No vague "what ifs".
  • Evidence grade: A (strong: direct data, proof, reproducible), B (moderate: solid reasoning or indirect data), C (weak: plausible but thin), D (anecdotal or assumed). Grade the evidence behind the position.
  • Assumptions: what must be true for this position to hold.
  • Confidence: 0 to 100.

Record all Round 1 positions and confidences. These are the independent votes; you will need them again in Phase 4.

Phase 3: Anonymized deliberation (subagents)

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:

  1. Steelman the strongest position that opposes its own, before rebutting it.
  2. State explicitly what would change its mind.
  3. Either hold or revise. A revision (a flip) MUST cite the specific new argument or evidence that caused it. A flip with no cited reason, or a flip that merely moves toward the apparent majority, is invalid and you will treat it as bandwagon in Phase 4.

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.

Phase 4: Foreman tally and synthesis (you, the foreman)

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:

  1. Confidence-weighted score per option, from the FINAL votes: sum each option's supporting jurors' confidences.
  2. Flip audit: for every juror who changed initial to final, check for a cited new reason. If more than half of the flips are unjustified, or every flip moved toward the earliest-stated majority, mark the deliberation SUSPECT.
  3. If SUSPECT: recompute the score using the INDEPENDENT Round 1 votes instead, take that winner, and cap confidence at LOW. Say plainly that deliberation showed bandwagon signs and you fell back to the independent aggregate. (Independent aggregation often beats degraded deliberation.)
  4. Else: the verdict is the final confidence-weighted winner.
  5. Tie or near-tie (top options within ~10 percent): do NOT coin-flip and do NOT abstain. Decide on the merits: pick the option with the higher evidence grade that best survived the devil's advocate's strongest challenge, per the rubric.
  6. Homogeneity cap: if the panel had low real diversity (same model, generic personas, near-unanimous from the start), drop the confidence one level and state that effective independence was low, so consensus is weak evidence.

The verdict is mandatory. At worst you return LOW or PIVOT confidence with the least-bad option plus a test, never "no decision".

Show full SKILL.md (861 more words)Show less
Phase 5: Emit the verdict

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.

Verdict format (mandatory shape)

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:

  • HIGH: genuine consensus that survived the devil's advocate, evidence mostly grade A or B, real panel diversity.
  • MEDIUM: confidence-weighted majority with a clear margin, or consensus on grade B or C evidence, with some objection unresolved.
  • LOW: narrow or weighted split, evidence mostly grade C or D, or a bandwagon fallback to the independent aggregate.
  • PIVOT: the panel judges the question itself is mis-framed. Still mandatory: give the least-bad action under the current framing AND state the reframe. Never use PIVOT to avoid deciding.

Constraints

MUST DO
  • Always produce a verdict. No abstention, ever.
  • Run the blind Round 1 before any juror sees another juror's opinion.
  • Assemble a diverse panel with a mandatory devil's advocate.
  • Anonymize positions during deliberation.
  • Require every flip to cite a concrete new reason; treat unjustified or majority-chasing flips as bandwagon and fall back to the independent aggregate.
  • Decide ties on argument quality against the rubric, not on vote count alone.
  • Calibrate confidence to real panel diversity and evidence grade; state the caveat when independence is low.
  • Keep the verdict in the ADHD-friendly shape: decision first, max 5 ranked reasons, preserved dissent, one next action.
MUST NOT
  • Strawman any position.
  • Manufacture disagreement for its own sake (a genuine dissenter is required, forced theatrics are not).
  • Let vote count override argument quality when persuasion or sycophancy is suspected.
  • Reveal juror identities during deliberation.
  • Exceed 2 deliberation rounds.
  • Oversell a homogeneous panel's consensus as certainty.
  • Lecture about the frameworks or name-drop the research; apply it silently.
  • Pad the verdict with preamble, recap, or "let me know if" closers.

Examples

Example 1: Engineering tradeoff

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:

  1. Frame: options A (tune current engine) vs B (migrate hot tables). Rubric: write latency, migration risk, reversibility, engineering cost. Shared evidence: current p99, compaction metrics, team size, deadline.
  2. Assemble 5: Proponent (migrate), Devil's advocate (tune), Integrator, plus a reliability persona (pre-mortem lens) and a cost persona (evidence-audit lens).
  3. Blind Round 1: reliability juror grades the "migration is low risk" claim as D and picks A at 80; proponent picks B at 70; etc.
  4. Deliberate: proponent flips to A after conceding, with cited reason, that no dual-write validation plan exists. Integrator holds A.
  5. Tally: weighted majority A, no bandwagon (flip was evidence-cited), evidence grade B. Confidence MEDIUM.

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.
Example 2: General decision (build vs buy)

User says: "Painel para decidir: construir nosso conector de billing ou comprar o SaaS X?"

Actions:

  1. Frame options build vs buy; rubric: total cost over 3 years, control over roadmap, time-to-value, switching cost. Shared evidence: pricing, current volume, in-house capacity.
  2. Assemble 3: Proponent (buy), Devil's advocate (build), Integrator.
  3. Blind Round 1, then anonymized deliberation, adaptive stop after Round 2 (positions stable).
  4. Tally: split 2 to 1 but the build case rests on grade C capacity assumptions; foreman decides on merits.

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.

Reference files (read on condition)

  • 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.

Troubleshooting

The panel is unanimous from Round 1

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.

Jurors keep flipping every round

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.

The vote is a hard tie

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.

A juror refuses to commit ("it depends")

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.

© tech-leads-club, CC-BY-4.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (scripts, references) in packages/skills-catalog/skills/(decision-making)/the-jury of tech-leads-club/agent-skills.

  • SKILL.md
  • references/deliberation-craft.md
  • references/juror-archetypes.md
  • scripts/tally.py

Open the folder on GitHubat commit 6df68d5

Compare with similar skills

The Jury next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

The Jury compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
The Jury this skilltech-leads-club/agent-skills7k—~4.5kAutomated safety check: PassCC-BY-4.0
Adversarial ReviewDanMcInerney/architect-loop626—~1.1kAutomated safety check: PassMIT
Dialecticumputun/cc-thingz485—~756Automated safety check: NotesMIT
Claude Code Agent Developmentanthropics/claude-plugins-official38k7 repos~2.8kAutomated safety check: PassApache-2.0
Grillingpietheinstrengholt/rssmonster56431 repos~510Automated safety check: PassMIT
Subagent Driven DevelopmentAsvarox/allkaraoke26138 repos~1.2kAutomated safety check: PassNone

Similar skills

  • Adversarial Review

    DanMcInerney/architect-loop

    A skill your agent uses when the architect factory orchestrator dispatches a fresh strategist subagent to harden a draft spec: falsify it with file:line evidence, fold the surviving findings into a…

    626 GitHub stars~1.1k tokensUpdated 28 days ago
    Agent WorkflowsAuto-check passed
  • Dialectic

    umputun/cc-thingz

    Prove and counter-prove a statement using parallel agents to eliminate confirmation bias.

    485 GitHub stars~756 tokensUpdated 5 days ago
    Agent WorkflowsAuto-check: notes
  • Claude Code Agent Development

    anthropics/claude-plugins-official

    Official

    Explains how to write agents for Claude Code plugins: the markdown file with YAML frontmatter, trigger descriptions, model and color settings, and system prompt design.

    38k GitHub starsUsed in 7 repos~2.8k tokens
    Agent WorkflowsAuto-check passed
  • Grilling

    pietheinstrengholt/rssmonster

    Grill the user relentlessly about a plan, decision, or idea.

    564 GitHub starsUsed in 31 repos~510 tokens
    Agent WorkflowsAuto-check passed
  • Subagent Driven Development

    Asvarox/allkaraoke

    A skill your agent uses when executing implementation plans with independent tasks in the current session

    261 GitHub starsUsed in 38 repos~1.2k tokens
    Agent WorkflowsAuto-check passed
  • Dispatching Parallel Agents

    ultralisp/ultralisp

    A skill your agent uses when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

    258 GitHub starsUsed in 41 repos~1.5k tokens
    Agent WorkflowsAuto-check passed

More from tech-leads-club/agent-skills

All 74 skills in this repo
  • Evolutionary Modular Architecture

    tech-leads-club/agent-skills

    Guides design of modular-monolith platforms with DDD, flat-by-aggregate modules, anti-corruption layers, outbox events and resilience, plus an architecture document with SVG diagrams.

    7k GitHub stars~3.7k tokensUpdated 2 days ago
    Auto-check passed
  • Excalidraw Diagram Studio

    tech-leads-club/agent-skills

    Generates Excalidraw diagram files from plain descriptions, choosing among flowcharts, mind maps, architecture, swimlane, class, sequence and ER diagrams.

    7k GitHub stars~3.6k tokensUpdated 2 days ago
    Auto-check passed
  • Mermaid Studio

    tech-leads-club/agent-skills

    Creates, validates and renders Mermaid diagrams to SVG, PNG or ASCII, including C4 and AWS architecture-beta, flowcharts, sequence diagrams and ERDs.

    7k GitHub stars~4.6k tokensUpdated 2 days ago
    Auto-check passed
  • AWS Cloud Advisor

    tech-leads-club/agent-skills

    Answers AWS architecture, security and service-selection questions by searching AWS documentation through MCP tools first, then adapting advice to your stack and team.

    7k GitHub stars~2.1k tokensUpdated 2 days ago
    Auto-check passed
  • Harness Eval

    tech-leads-club/agent-skills

    Evaluates a repository's agent harness (AGENTS.md, rules, skills) for broken paths, redundant instructions and usefulness, and stops at reports.

    7k GitHub stars~3.9k tokensUpdated 2 days ago
    Auto-check passed
  • NestJS Modular Monolith Architect

    tech-leads-club/agent-skills

    Designs scalable NestJS modular monoliths with domain-driven design, Clean Architecture layers and optional CQRS, defining bounded contexts and strict module boundaries.

    7k GitHub stars~3.9k tokensUpdated 2 days ago
    Auto-check passed

Categories

Questions about The Jury

What does The Jury do?

A skill your agent uses when a question, decision, plan, tradeoff, or claim needs a rigorous verdict and one perspective is not enough. The Jury is an agent skill from tech-leads-club/agent-skills. Use when a question, decision, plan, tradeoff, or claim needs a rigorous verdict and one perspective is not enough.

When should I use The Jury?

The Jury fits situations like: claim needs a rigorous verdict and one perspective is not enough; phrases include convene a jury; have agents debate and decide; get a panel to decide.

How do I install The Jury in Claude Code?

Run `npx skills add tech-leads-club/agent-skills --skill the-jury -a claude-code`. Or copy the skill folder (packages/skills-catalog/skills/(decision-making)/the-jury in tech-leads-club/agent-skills) into .claude/skills/the-jury in your project. Claude Code loads it when a task matches its description.

How do I install The Jury in Codex?

Run `npx skills add tech-leads-club/agent-skills --skill the-jury -a codex`. Or copy the skill folder (packages/skills-catalog/skills/(decision-making)/the-jury in tech-leads-club/agent-skills) into .agents/skills/the-jury in your project. Codex loads it when a task matches its description.

Can I use The Jury in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add tech-leads-club/agent-skills --skill the-jury -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/the-jury, .gemini/skills/the-jury, .github/skills/the-jury and .opencode/skills/the-jury in your project.

What does The Jury need to run?

Going by SKILL.md and its folder, The Jury needs Python for the scripts in its folder and the command-line tools its instructions call (python). Our summary lists: Python 3.

Does The Jury access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is The Jury safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does The Jury use?

The Jury is published under the CC-BY-4.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does The Jury use?

About 4.5k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 4.1k tokens, read only when the agent opens those files.

What are the alternatives to The Jury?

Skills that share tags, products or a category with The Jury: Adversarial Review (DanMcInerney/architect-loop, 626 stars), Dialectic (umputun/cc-thingz, 485 stars), Claude Code Agent Development (anthropics/claude-plugins-official, 38k stars) and Grilling (pietheinstrengholt/rssmonster, 564 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains The Jury?

tech-leads-club (a GitHub organization) maintains it in tech-leads-club/agent-skills, which has 7,045 GitHub stars. The repository holds 74 skills in this directory. The repository was last updated on October 9, 2026.

Source: tech-leads-club/agent-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.