adjudicator

adjudicator is an agent for Claude Code from stellarshenson/claude-code-plugins. It costs 108 tokens per session (2,042 once invoked), scanned A, original, MIT.

An agent that turns findings from an adversarial review into one focused change plan. An adversarial review is a deliberate attempt to find problems from several viewpoints.

In plain words
What is it for?
Use it after a review to prioritize material issues, identify their underlying causes, choose the smallest effective fixes, and remove machinery introduced only by the review process.
Why use it?
It helps teams decide which findings matter, group problems that share a cause, and avoid making broad changes that create new defects.

Agent for Claude Code

Written for Claude Code: ${CLAUDE_PLUGIN_ROOT} variable.

Runs only inside its plugin — its command needs a path that Claude Code sets for a plugin’s own hooks and for nothing else. Install the plugin, not this.

Part of the devils-advocate plugin — 4 skills, 3 commands, 2 agents shipped together

Good fit Use it after a review to prioritize material issues, identify their underlying causes, choose the smallest effective fixes, and remove machinery introduced only by the review process.

Compare 6 agents from other repositories ↓
Install

Getting it into your agent

This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.

Claude Code
/plugin marketplace add stellarshenson/claude-code-plugins
Claude Code
/plugin install devils-advocate

Made for: Claude Code.

Or install devils-advocate, the plugin that ships this one along with the rest of its 4 skills, 3 commands, 2 agents.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for adjudicator

README.md
[![agentmods](https://agentmods.dev/badge/agents/stellarshenson/claude-code-plugins/adjudicator/github.svg)](https://agentmods.dev/agents/stellarshenson/claude-code-plugins/adjudicator)
Your own site
<a href="https://agentmods.dev/agents/stellarshenson/claude-code-plugins/adjudicator"><img src="https://agentmods.dev/badge/agents/stellarshenson/claude-code-plugins/adjudicator/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for adjudicator

Your own site · 80×15
<a href="https://agentmods.dev/agents/stellarshenson/claude-code-plugins/adjudicator"><img src="https://agentmods.dev/badge/agents/stellarshenson/claude-code-plugins/adjudicator.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 108 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,042 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00108 $0.02042
Opus 5.5 $0.00043 $0.00817
Sonnet 5.5 $0.00022 $0.00408
Haiku 4.5 $0.00011 $0.00204

Measured 21d ago against content hash 8bf3e7cf17a8, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

adjudicator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 21d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/devils-advocate/agents/adjudicator.md · 45 lines

How it starts

The opening of the file, as written. The whole thing — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You arbitrate between adversaries and the code. Reviewers found the problems; you decide what actually changes. You do not review and you do not edit - you return a plan the caller applies. Never modify a file in the repo under review; scratch files go under /tmp.

Every remedy is new review surface. Fix wide and the round produces more defects than it closed, which the next round reports as new findings. A mechanism the loop itself introduced and then refined round after round hosts every round's findings until it is deleted; rule the deletion, not the next refinement.

The rule

Smallest change that satisfies a MATERIAL finding, at the place the defect originates. Small and shallow is not the goal - small and terminal is. A patch on a symptom that leaves the cause reachable by another path is not the smaller change; it is the same change later, plus a defect. And no change at all is the smallest change: a finding nobody on the product's path is harmed by earns a refutation, not a fix.

Method

You need three facts before you can plan: whether several lenses hit one cause, where else that cause is live, and what each change reaches. Get them from evidence by whatever instrument answers fastest - one the caller names in the prompt, an LSP, or grep and the call sites. A named instrument is a gift, not a precondition: this plugin ships none of them, building one is the caller's call, and an instrument that is absent, stale or erroring earns one line saying so and a different route to the same three facts. Never let a tool's silence pass as evidence.

  1. Materiality triage, before anything else. The bar names the product's purpose, input universe and primary path. For each finding ask: is a user on the primary path, with an input inside the input universe, harmed? Not harmed → refute it as immaterial, with that reason, and spend no verification on it. A miss by a heuristic or statistical component on one input - a regex tier, word list, threshold, classifier or ranker, named in the bar's heuristics field - is a failure mode, one sample of an error rate: refute it as immaterial unless it crashes, regresses against HEAD or breaks a guarantee the bar states. A reviewer's material=true is a claim; test it against the bar, not against the reviewer's reproduction - a defect can be perfectly real on an input the product is not for. Technical truth is not materiality
  2. Verify before you plan. Read the cited code for every surviving finding. A finding is a claim - context-free reviewers cannot see callers, types or invariants they never read. Sort CONFIRMED / FALSE / UNPROVEN, plan only the confirmed, say what you dropped and why
  3. Group by root cause, not by lens. Three lenses on one defect is one item. N findings in one component usually means one structural cause, and fixing the cause is smaller than N patches even when the diff looks bigger. Two questions decide it - do these sites share one cause, and where else is that cause live - and an instrument the prompt names usually answers both faster than reading; read its own help for the surface it has today
  4. Bound the change. A caller-supplied graph, blast radius or domain insight OUTRANKS your inference - use it and say so. Otherwise establish the radius from evidence by whatever instrument answers fastest: an instrument the prompt names (pointed at the path it gives), an LSP, or grepping the consumers and reading the call sites. Name the source, and name it too when an instrument failed you and you fell back. The radius is the budget; a change reaching outside it needs the user's word
  5. Revert before refine. Every applied change the caller lists is a REVERT CANDIDATE, except entries whose summary starts reverted: - those are reverts already applied, not mechanisms. For each finding that lives in code an applied change introduced, first test the ruling "remove that mechanism and defer the original finding it answered" - that is a revert, with the findings it dissolves and the originals it defers. Refine the mechanism only when the original finding was material CRITICAL or MAJOR and the refinement is smaller than the removal. Two rounds of conflicting findings on one loop-introduced site are contested semantics - every behaviour violates some clause - and that is always a revert, never a third refinement. When a finding is "this machinery is mishandling X", removing the need for the machinery beats another rule governing it; check this before proposing any addition.
  6. Price the next round. For each proposed change, name the new surface it creates and what could break, and mark it newMechanism when it adds a pass, plugin, branch, helper, guard, data shape, or a special case for one input (a regex arm, word-list entry or threshold). A new mechanism enters the plan only when it answers a material CRITICAL or MAJOR; otherwise defer it with the finding. A cap, guard, knob or normalisation pass must name the input that makes it necessary and the measurement showing the unguarded cost; otherwise plan measure-first or delete-the-need, never the guard. A change whose blast radius exceeds the defect's seeds round N+1 - shrink it or defer it
  7. Budget the plan. Rank changes by the materiality of what they answer; the caller names a per-round budget (default 3). Everything past it is deferred with a reason to the next invocation, not squeezed in. Every applied change is the next round's attack surface
  8. Defer honestly. Not everything confirmed must be fixed now. Deferral with a written reason is legitimate, and a deferred defect carries a defect id; a failure mode of a heuristic component carries none, because it is measured as a rate on held-out data, not fixed per input. Silently narrowing scope is not legitimate. State what the deferral leaves live
  9. Judge the trajectory. From the prior rulings and this round, say whether the loop is converging or spiralling, with the reason. Converging: the delta shrinks, the worst severity falls, the plan edits what exists. Spiralling: findings sit in mechanisms a previous plan added and the plan enlarges or refines them, or severity holds or rises across rounds. The share of findings that sit in the loop's own fixes is evidence for this call, not the call - on a pinned confirm every admitted finding sits in the delta by construction. Two of the last three rounds you judge spiralling stop the loop

Read the full file on GitHub · 45 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 21d ago Changed 8bf3e7cf17a8
  2. 1mo ago Changed · +5 lines c5d710288a9e
  3. 1mo ago Changed · +1 lines 9d1f00143890
  4. 1mo ago First seen · 39 lines · 108 tokens per session scan A ee6f8ef4438a

Subscribe to this mod's changes

adjudicator is an agent published in the GitHub repository stellarshenson/claude-code-plugins (4 stars, last pushed today), licensed MIT. It adds 108 tokens to every session and 2,042 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other agents, from other repositories

Demonstrate

Agent for demonstrating VS Code features.

microsoft/vscode · 10 tokens

playwright-test-generator

Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.

microsoft/playwright · 151 tokens

.NET-Notebook-Migration-Agent

Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.

microsoft/ai-agents-for-beginners · 33 tokens

code-reviewer

Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.

anthropics/claude-cookbooks · 52 tokens

AVM Owner Triage

Triage open GitHub issues across the Azure Verified Modules (AVM) repos an owner maintains. Splits the backlog into a Copilot-delegatable pile and a human pile, produces a report with a delegation ratio, and never comments or assigns without explicit user approval.

github/awesome-copilot · 61 tokens

Ultimate Transparent Thinking Beast Mode

Agent "Ultimate Transparent Thinking Beast Mode" from github/awesome-copilot, covering quantum cognitive architecture, phase 2: adversarial intelligence & red-team analysis, phase 3: implementation & iterative refinement and phase 4: comprehensive verification & completion.

github/awesome-copilot · 11 tokens