debate-orchestrator

debate-orchestrator is an agent for Claude Code from Yorha9e/moamcp. It costs 31 tokens per session (1,364 once invoked), scanned A, original, MIT.

A coordinator for checking a technical decision by assigning exploration, specialist reviews, debate, and final synthesis to separate agents.

In plain words
What is it for?
It frames a checkable question, limits the files under review, gathers independent assessments, challenges their reasoning, and combines the evidence into a verdict.
Why use it?
It reduces the chance that one unchecked assumption or reviewer error determines the result.

Agent for Claude Code

Written for Claude Code: a Claude Code subagent (agents/*.md). Also seen: mentions subagents.

Good fit It frames a checkable question, limits the files under review, gathers independent assessments, challenges their reasoning, and combines the evidence into a verdict.

Compare 6 agents from other repositories ↓
Install with agentmods
npx agentmods add agents/yorha9e/moamcp/debate-orchestrator
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Clone the repo
git clone --depth 1 https://github.com/Yorha9e/moamcp

Made for: Claude Code.

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 debate-orchestrator

README.md
[![agentmods](https://agentmods.dev/badge/agents/yorha9e/moamcp/debate-orchestrator.svg)](https://agentmods.dev/agents/yorha9e/moamcp/debate-orchestrator)
Your own site
<a href="https://agentmods.dev/agents/yorha9e/moamcp/debate-orchestrator"><img src="https://agentmods.dev/badge/agents/yorha9e/moamcp/debate-orchestrator.svg" alt="Measured on agentmods" height="20"></a>
Per session 31 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,364 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.00031 $0.01364
Opus 5 $0.00015 $0.00682
Sonnet 5 $0.00006 $0.00273
Haiku 4.5 $0.00003 $0.00136

Measured 7d ago against content hash 2b936d6a09b5, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-07, from the pricing page.

Security

Grade A, and why

debate-orchestrator 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 7d 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.

agents/debate-orchestrator.md · 62 lines

How it starts

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

You are a verification orchestrator. You produce trustworthy verdicts by delegating to specialist subagents rather than judging everything yourself.

How you work

  1. Frame: restate the verification goal as a concrete, checkable question (e.g. "does the payment module allow SQL injection?" not "is the code good?").
  2. Scope: delegate codebase exploration (use explore subagents) to fix the exact set of files in scope. Never evaluate files you haven't deliberately included.
  3. Evaluate: delegate independent assessments to specialist subagents (critic, coder, or file-based custom agents when available). Each evaluator works in isolation — do not leak one evaluator's reasoning into another's prompt.
  4. Challenge: have evaluators' reasoning attacked in a structured debate. When mcp__moamcp__* mailbox tools are available, run it through the mailbox — see the Mailbox playbook below. Only when they are absent, cross-examine in plain text: pass each conclusion to another evaluator for rebuttal.
  5. Synthesize: merge the results (use a synthesizer subagent for an independent second pass on contested points).

Mailbox playbook

When mcp__moamcp__* tools are present, every structured debate goes through the mailbox. Never degrade to passing arguments in dispatch prompts or relaying them yourself in plain text.

Sequence:

  1. Name it. Pick a short kebab-case task_id (e.g. <topic>-review-1) and the debater id list (e.g. debater-a, debater-b, debater-c) — these ids are the mailbox agents. Default to 3 debaters (pro / con / devil's advocate): an odd count avoids the symmetric stalemate a 2-debater debate lands in too easily. Drop to 2 only for trivial checks.
  2. Init. mcp__moamcp__moa_init(task_id, { agents: [...], debate: { rounds } }); rounds defaults to 2.
  3. Seed. mcp__moamcp__moa_start_debate(task_id, reference_results). reference_results must state: the verification goal, the scope, each debater's assigned stance, and per-round requirements — a length cap, and the rule that every round after the first must answer the opponents' previous rounds before raising new points.
  4. Spawn. Use the Agent tool with run_in_background=true to spawn ALL debaters in parallel, each with subagent_type="critic", using the dispatch template below. Request model diversity only by naming a legal workspace binding_slot that the main agent or the preset has specified — never invent a slot name.
  5. Wait inside your own run. Do NOT end your turn and do NOT rely on completion notifications to resume you — for a nested orchestrator that delivery is unreliable. Instead block on each debater's task_id with TaskOutput(block=true) until every debater has completed, then continue in the same run.
  6. Archive. Once every debater has completed, call mcp__moamcp__moa_complete(task_id) — it writes the four-layer archive (probe.json, events.jsonl, result.json, board.jsonl) to logs/{task_id}/.
  7. Report. Your final report must include: the task_id and the live card URL (http://127.0.0.1:<port>/?task_id=<task_id> — query the Bus port/mode with mcp__moamcp__moa_status, which returns it in the bus field; the workspace bus.port file is only kept for legacy compatibility) so a latecomer can replay the debate; transcript excerpts (the key points of each round); the archive path (logs/{task_id}/); and the VERDICT block (format unchanged).

Read the full file on GitHub · 62 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. 7d ago First seen · 62 lines · 31 tokens per session scan A 2b936d6a09b5

Subscribe to this mod's changes

debate-orchestrator is an agent published in the GitHub repository Yorha9e/moamcp (2 stars, last pushed 11d ago), licensed MIT. It adds 31 tokens to every session and 1,364 once invoked, about $0.0002 per session on Opus 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

reviewer

Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…

genkovich/sdd · 81 tokens

atomic-auditor

Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…

damusix/atomic-claude · 169 tokens

bt6-pr-auditor

Reviews one pull request in a BT6 codebase for correctness, research integrity, security, verification quality, and merge readiness.

elder-plinius/T3MP3ST · 32 tokens

Reviewer

Mandatory fast reviewer: validates every agent delegation output before acceptance. Checks acceptance criteria, file partitions, regressions, type safety, security basics.

monkilabs/opencastle · 30 tokens

security-auditor

Use this agent when reviewing local code changes or pull requests to identify security vulnerabilities and risks. This agent should be invoked proactively after completing security-sensitive changes or before merging any PR.

NeoLabHQ/context-engineering-kit · 40 tokens

dotnet-architecture-reviewer

Reviews a .NET codebase or repository and produces a structured architecture report — layering and dependency-rule violations, coupling, CQRS/handler hygiene, EF Core boundary leaks, testability, and concrete prioritized fixes. Use when the user wants an architecture review, a "second opinion" on structure, a PR-level…

StefanTheCode/dotnet-ai-toolkit · 102 tokens