/kill-argument

name: kill-argument
description: "Two-thread adversarial review: a fresh reviewer constructs the strongest 200-word rejection memo, then a second fresh reviewer defends the paper point-by-point and surfaces still-unresolved critical issues. Use when user says \"kill argument\", \"adversarial review\", \"hostile review\", \"rebuttal preparation\", \"reviewer-2 simulation\", or before submitting a theory paper that has already passed standard review rounds."
argument-hint: "[paper-directory]"
allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, mcp__codex__codex

Kill Argument Exercise: Adversarial Attack-Defense Review

> 🔒 **Do not wrap this skill in `/loop`, `/schedule`, or `CronCreate`.** It is > verdict-bearing — it produces an adversarial accept/reject verdict (attack → > adjudication). Re-firing it on a wall-clock timer adds no new signal (the > attack changes only when the *paper* changes). Schedule the *external wait > that precedes it* — draft stable → then run this **once** before submission. > See > [`shared-references/external-cadence.md`](../shared-references/external-cadence.md).

Stress-test the headline claims of a paper against the strongest possible rejection argument: **$ARGUMENTS**

Why This Exists

Standard score-based reviews (`/research-review`, `/auto-paper-improvement-loop`) tend to produce **balanced** weakness lists. Each weakness gets ~equal attention, ranked CRITICAL > MAJOR > MINOR. Empirically, this misses one specific failure mode: the **single most damaging argument** a reviewer would write in a rejection paragraph — the one sentence that, if a senior area chair reads it, kills the paper.

A balanced reviewer might list "scope-overclaim risk" as MAJOR alongside 3-5 other MAJORs, never quite committing. An adversarial reviewer **must commit**: their entire job is to convince the area chair to reject in 200 words.

This skill runs that adversarial pass deliberately, then forces a second fresh reviewer to defend point-by-point, classify each rejection as already-fixed / partially-fixed / still-unresolved, and surface what's actually load-bearing.

**Empirical motivation:** in a real submission run, after several rounds of standard improvement (score 7-8/10), the kill-argument exercise surfaced framing weaknesses that no prior review caught (e.g., a setting being mostly conditional rather than truly general, or a baseline being irrelevant to real systems). Author rebuttal forced explicit scope qualifications in abstract and discussion that weren't visible from the score-based reviews alone.

How This Differs From Other Review Skills

| Skill | What it asks the reviewer | Output | |-------|---------------------------|--------| | Standard peer review | "Score this paper, list weaknesses by severity" | balanced weakness list | | `/research-review` | "Deep technical review of methods + claims" | structured deep critique | | `/proof-checker` | "Is this theorem actually proved?" | per-step proof obligation audit | | `/paper-claim-audit` | "Does the paper report numbers truthfully?" | per-claim evidence verification | | `/citation-audit` | "Are citations real and used in correct context?" | per-entry KEEP/FIX/REPLACE/REMOVE | | **`/kill-argument`** | **"Write the single strongest rejection paragraph; then defend it."** | **attack memo + per-point defense + unresolved surfaced** |

This skill is **complementary**, not a replacement. Run after standard reviews when you want to know what the worst-case reviewer paragraph would look like, before camera-ready or rebuttal preparation.

When To Use

• After 1-2 rounds of `/auto-paper-improvement-loop` settled at a stable score, but before submission. Surfaces what additional fixes would close the headline-attack gap.
• During rebuttal preparation, to predict reviewer-2's strongest objection so you can prepare the response in advance.
• For theory papers with a high-level title that may oversimplify the actual theorem (the most common reject-attack pattern).
• For papers where a reviewer might attack scope, assumption-vs-claim mismatch, missing proof obligations, or evidence-vs-headline gaps.

This skill is most valuable for **theory papers** with ≥5 theorem-class environments (so the headline depends on real proof obligations). For empirical papers without theorems, use `/research-review` instead.

Constants

• **REVIEWER_MODEL** = `gpt-5.6-sol` (default; `gpt-5.5` is the capability fallback, `gpt-5.4` only as an explicit legacy override). Reviewer reasoning effort = `ultra` for the attack / defense / adjudication threads (deep-audit tier; capability fallback per `shared-references/reviewer-routing.md`, never below `xhigh`). Beast-mode axis probes stay at `xhigh`.
• **CONTEXT_POLICY** = `fresh` (REVIEWER_BIAS_GUARD). Each thread is a fresh `mcp__codex__codex` call. **Never** use `mcp__codex__codex-reply`. No prior review summary, fix list, or executor explanation enters either prompt.
• **ATTACK_LENGTH** = approximately 200 words (do not exceed 250). Single coherent argument, not a list.
• **DEFENSE_DECOMPOSITION** = 3-7 atomic rejection points extracted from the attack memo. Each gets its own classification.
• **CLASSIFICATION** = `answered_by_current_text` / `partially_answered` / `still_unresolved`. (Names chosen so the adjudicator does not assume "fixed" implies prior history of patching — they read the paper as a fresh reviewer would.)
• **OUTPUT** = `KILL_ARGUMENT.md` (human-readable) + `KILL_ARGUMENT.json` (machine-readable) in the paper directory.
• **RENDER_HTML = true** — When `true` (default), auto-render `KILL_ARGUMENT.md` to HTML after writing the report. Uses **full Codex review gate** (audit-class artifact — full render-fidelity check matches the skill's cross-model audit invariant; the sidecar `KILL_ARGUMENT.json` is also passed to the renderer). Set `false` to skip, or pass `— render html: false`.

Workflow

Step 1: Discover paper files

Locate the paper direct