Debate

Adversarial Debate (cross-model)

Run a structured adversarial review using an external reviewer model. This skill handles the full debate lifecycle: drafting, invoking the reviewer, responding, and recording outcomes. The reviewer is a different model from Claude — the cross-model gap is where the value comes from.

Two reviewer backends are supported, selected per invocation (see Reviewer Selection below):

• codex — OpenAI Codex CLI. Model-pinnable, stable, and the existing corpus of critique logs was built with it.
• agy — Google Antigravity CLI (Gemini). The forward path as Codex's free tier winds down.

The entire debate protocol — draft, self-review, response cycle, critique log, summary, index — is identical regardless of backend. Only the Reviewer CLI Invocation section branches by model. Throughout this skill, ` is a placeholder for the chosen backend (codex or agy); it appears in filenames and in the critique log's source` field so cross-model results stay comparable.

Reviewer Selection

Pick the backend at invocation time:

• Explicit flag: /debate --model agy or /debate --model codex .
• If the user names a model in prose ("debate this with agy"), honor it.
• Default when unspecified: codex. It is the proven-reliable backend, supports inline model pinning, and keeps the critique-log corpus consistent with prior debates (catch-rate trends stay comparable). Switch the default to agy once its reviewer model is reliably pinned to a Pro tier and its auth is stable in this environment.

Record the chosen backend in the draft header and carry it through every file name and log entry for the debate.

Git Handling

Debate files split into two tiers: searchable artifacts worth tracking, and raw process logs that aren't. Drafts, self-reviews, critiques, responses, and rebuttals are scratch paper — they are load-bearing during the debate and noise afterward. Summaries, critique logs, and the index are the searchable residue that has cross-debate reuse value (decision history, catch-rate tracking, "have I debated this before?" queries).

Default pattern — track summaries, gitignore the rest. In the project's .gitignore:

debate/*
!debate/INDEX.md
!debate/*-summary.md
!debate/*-critique-log.json

This commits INDEX.md, each debate's *-summary.md, and the structured *-critique-log.json files. Everything else (drafts, self-reviews, raw critiques, rebuttals, snapshots) stays local.

Rationale:

• Summaries distill the conclusions. They're what a reader actually needs.
• Critique logs are small, structured, and enable pattern recognition across debates (severity distributions, self-review catch rate trends, which critiques were rejected vs adopted).
• Raw rebuttals and drafts are verbose, context-specific, and rarely re-read. Keeping them out of git avoids repo bloat and leaking in-progress reasoning.
• INDEX.md is the directory — without it, committed summaries are orphaned.

Exception — full tracking: If the project specifically studies the debate process (methodology research, prompt engineering on the skill itself), commit everything. That's rare.

Exception — nothing tracked: If the debate outcome was fully incorporated into an ADR or plan file that's already committed, and no one will ever search for the debate again, gitignoring the whole debate/ directory is fine too.

Before the first debate in a project, check if debate/ is gitignored. If not, suggest adding the default pattern above. If it's already fully gitignored (the old default), suggest upgrading to the summaries-tracked pattern so the corpus accumulates.

Reviewer CLI Invocation

This is the only section that branches by backend. Steps 3 and 6 reference "invoke the reviewer" — use the block matching the selected ``. The prompt body (adversarial framing, type-specific blocks, Munin instructions) is identical across backends; only the command wrapper and output-capture mechanics differ.

Backend: codex

Correct syntax:

script -q /dev/null codex exec --sandbox workspace-write --skip-git-repo-check -m gpt-5.5 -c model_reasoning_effort='"xhigh"' "" 2>&1

Important rules:

• Wrap with script -q /dev/null to provide a pseudo-TTY (Codex auth fails without one when invoked from Claude Code)
• Use codex exec --sandbox workspace-write — NOT codex -q, and NOT the deprecated --full-auto (Codex 0.132+ warns and --sandbox workspace-write is the replacement). Add --skip-git-repo-check so it runs in non-git working dirs too (e.g. ~/mimir/mgc); without it Codex refuses with "Not inside a trusted directory".
• Always pin the strongest model and effort for debates: -m gpt-5.5 -c model_reasoning_effort='"xhigh"'. gpt-5.5 is the current Codex-recommended frontier model; verify with codex exec -m gpt-5.5 ... before relying on it. If unavailable in the active account (e.g., API-key auth without ChatGPT sign-in), fall back to -m gpt-5.4. Debates are high-stakes adversarial reviews — use the strongest available model at "Extra High" effort, not the global config.toml default (which is tuned for everyday use). The '"xhigh"' quoting is intentional: the outer single quotes protect from shell interpolation, the inner double quotes make the value a TOML string literal.
• Do NOT use the -o flag to capture critique content. The -o flag writes Codex's final conversational summary, not the file it created. Instead, instruct Codex to write its output file directly (it has workspace-write access via --sandbox workspace-write).
• Set --timeout 300000 on the Bash tool call (Codex can take a few minutes; with xhigh effort it may run longer — consider --timeout 600000)
• Codex works in the repo's working directory and can read all project files

Backend: agy (Antigravity / Gemini)

Correct syntax:

agy --print --dangerously-skip-permissions "" 2>&1

Important rules:

• agy --print runs a single prompt non-interactively. No pseudo-TTY wrapper is needed (unlike Codex), but auth must already be established (see auth note below).
• --dangerously-skip-permissions is required in headless mode — without it, agy blocks on a permission prompt the moment it tries to read a file, run a command, or call an MCP tool, and the run hangs until it times out. The debate prompt only asks agy to read project files and (optionally) call Munin, so the scope is bounded.
• Add --add-dir if the debate files live outside agy's default workspace, so it can read the draft. From the repo root this is usually unnecessary.
• No per-prompt model flag exists. agy uses the model set via the sticky interactive /model command, which persists across sessions. The out-of-box default is Gemini 3.5 Flash — the fast/cheap tier, wrong for adversarial review. Before relying on agy for debates, set a Pro-tier reasoning model once: run agy interactively, type /model, pick the strongest Gemini (e.g. a 3.x Pro), exit. Verify the active model at the start of a debate by checking the reviewer's Context loaded header or asking it; if it reports Flash, warn the user and recommend they switch via /model before continuing — a Flash-tier critique is materially weaker and should be flagged in the summary.
• Capture critique via stdout, not a written file. agy on the Flash tier is chatty and unreliable at the "write your output to file X" instruction (it tends to narrate or run a handshake instead). The robust pattern is: instruct agy to print its complete critique to stdout as its final response, capture the Bash tool output, and have Claude write debate/-agy-critique.md from that output. (This is the same recovery path Codex uses in Step 4 when its file is missing — for agy, make it the default.)
• Set --timeout 300000 on the Bash tool call; raise to 600000 for large drafts.
• Auth note: agy's OAuth token expires (observed: hours to days) and --print will re-emit a Waiting for authentication URL when stale. agy writes auth prompts directly to the TTY, so they cannot be fed through a pipe — if a debate run prints an auth URL, stop and ask the user to refresh by running agy --print 'hi' interactively in their terminal (via the ! prefix), complete the browser flow, then re-run the debate step.
• agy works in the current working directory and can read project files (confirmed via its file tools); it also has Munin access (see below).

Munin Memory Access

Both backends have Munin access, so the live-context approach applies regardless of reviewer:

• Codex is configured with the full Munin memory tool surface (memory_read, memory_query, memory_orient, memory_history, memory_narrative, memory_commitments, memory_patterns, memory_insights, memory_handoff, memory_resume, memory_attention, memory_extract, memory_read_batch, memory_get, memory_list, memory_status).
• agy reaches Munin through a bridge (observed: it runs memory_orient on its own and resolves the same projects/* namespaces). Treat its memory surface as equivalent for debate purposes.

Use this to give the reviewer live project context instead of pasting a snapshot into the prompt.

Infer the Munin namespace from the current git repo before invoking the reviewer:

git remote get-url origin 2>/dev/null | sed -E 's|.*/([^/]+?)(\.git)?$|projects/\1|'

• Example: repo munin-memory → namespace projects/munin-memory
• If the repo name doesn't map cleanly (fork, monorepo, cross-cutting topic), ask the user. Do not guess.
• If there is no matching Munin namespace at all (new project, methodology debate, topic not yet represented), skip the memory access instructions in the reviewer prompt and note this in the draft.

Pass the inferred namespace as a placeholder substitution into the reviewer prompts in Steps 3 and 6. Do not pre-assemble context into a file — let the reviewer self-serve from Munin at critique time, so Round 1 and Round 2 read live state rather than a stale snapshot.

agy caveat: on the Flash tier, agy sometimes performs the full CLAUDE.md-style Munin handshake and wanders off-task. Keep its prompt tightly scoped — instruct it to load only the specific calls listed in Step 3 and then critique, nothing else.

Debate Protocol

Step 0: Snapshot the artifact

Freeze the artifact being reviewed so all review conditions run against the same version.

• Single file: Copy to debate/-snapshot.md (or appropriate extension).
• Multiple files: Create debate/-snapshot/ directory with copies.
• Already committed and won't change during debate: Record the reference instead:

`` Snapshot: commit , file(s): , ``

Step 1: Write the draft

Write Claude's position/assessment/plan to debate/-claude-draft.md.

Every draft must include these four sections, regardless of topic type:

## Assumptions
[List load-bearing assumptions — things that must be true for this to work]

## Failure Modes
[What goes wrong if this fails? How does it fail? What's the blast radius?]

## Alternatives Rejected
[What options were considered and discarded, and why]

## Unknowns
[What remains uncertain that could invalidate this position]

These sections give both self-review and the reviewer concrete material to attack. A draft without them is not ready for review.

Step 2: Self-review

Before invoking the reviewer, Claude critiques its own draft using the topic-specific checklist below. Write to debate/-claude-self-review.md.

Identify the debate type first and declare it as a structured field at the top of the self-review file:

## Debate Type
Primary: 
Secondary:  (omit if single-type)

This classification drives the type-specific prompts in Steps 3 and 6. For mixed-type debates, list the primary type first.

Then work through the relevant checklist. Be genuinely critical — this baseline reveals whether cross-model review adds value over self-review. The caught_by_self_review field in the critique log (Step 8) tracks this.

Universal checklist (all types)

• [ ] What assumptions in the draft might not hold? Are they listed in the Assumptions section?
• [ ] Are the failure modes exhaustive, or just the obvious ones?
• [ ] What's the strongest argument against my own position?
• [ ] What evidence or baseline is missing?
• [ ] What operational/maintenance burden is hidden or understated?

Security debates

• [ ] What are the trust boundaries? What crosses them?
• [ ] What happens if an attacker controls a key input or state?
• [ ] Are auth, authz, and session management failure modes covered?
• [ ] What's the blast radius of a compromise?
• [ ] Are secrets, keys, and credentials handled correctly throughout?

Architecture debates

• [ ] What scale, load, or data-size assumptions are baked in?
• [ ] What coupling is being introduced, and what does it preclude later?
• [ ] How does the system degrade under partial failure?
• [ ] What's the operational burden (deployment, monitoring, incident response)?
• [ ] What's the reversibility cost if this turns out to be wrong?

Protocol/API debates

• [ ] What are the edge cases in the protocol state machine?
• [ ] What happens to in-flight requests during failures or restarts?
• [ ] What does a client do when it gets an unexpected response?
• [ ] What's the versioning and backward-compatibility story?
• [ ] What are the timeout, retry, and idempotency semantics?

Docs/process debates

• [ ] What's the maintenance burden? Who keeps this updated?
• [ ] Where does this conflict with or duplicate existing documentation?
• [ ] What's the single source of truth, and is it unambiguous?
• [ ] What would a newcomer need that's missing here?

Priority/product debates

• [ ] What evidence supports this priority over alternatives?
• [ ] What are the opportunity costs of this choice?
• [ ] What assumptions about user or system behavior are load-bearing?
• [ ] What does "done" look like, and how would we know if it worked?
• [ ] What's the reversibility of this decision?

Step 3: Invoke the reviewer (Round 1 critique)

Read the ## Debate Type field from debate/-claude-self-review.md and include the matching type-specific block(s) below. The type-specific questions are additive — always include the universal adversarial framing, then layer on domain-specific attack vectors.

For mixed-type debates, include blocks for both primary and secondary types. Primary type block goes first.

The prompt body below is backend-independent. Wrap it in the command for the selected ` from the **Reviewer CLI Invocation** section (codex: script -q /dev/null codex exec --sandbox workspace-write --skip-git-repo-check -m gpt-5.5 ...; agy: agy --print --dangerously-skip-permissions ...`).

You are acting as a grounded but adversarial reviewer.

Read the file debate/-claude-draft.md. [Additional context files to read if needed.]

LOAD PROJECT CONTEXT FROM MUNIN FIRST. You have full access to Munin memory tools. Before critiquing, run these calls in order — then STOP using memory tools and critique; do not perform a general handshake or wander:
1. memory_read(namespace: '', key: 'synthesis') — load the current synthesized project state
2. If synthesis_age_days > 3, or the entry is marked stale, or missing → memory_read(namespace: '', key: 'status') as fallback
3. memory_query(query: '', tags: ['decision'], limit: 5) — surface prior decisions that may constrain or relate to this debate
4. Optionally call memory_history, memory_narrative, memory_commitments, or memory_patterns on the namespace if the debate type would benefit (architecture → narrative; priority → commitments; protocol → history)

Ground your critique in this live project state, not just the draft file. If the draft contradicts or omits something the memory

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Magnus-Gille](https://github.com/Magnus-Gille)
- **Source:** [Magnus-Gille/claude-skills](https://github.com/Magnus-Gille/claude-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.