ablation-planner
Use when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.
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
Claude Code
$ npx -y skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument --agent claude-code
Codex
$ npx skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument -a codex -y
Cursor
$ npx skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument -a cursor -y
Gemini CLI
$ npx skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument -a gemini-cli -y
GitHub Copilot
$ npx skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument -a github-copilot -y
OpenCode
$ npx skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument -a opencode -y
Windsurf
$ npx skills add wanshuiyin/Auto-claude-code-research-in-sleep --skill kill-argument -a windsurf -y
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, mcp__antigravity__antigravity, mcp__antigravity__antigravity-reply, mcp__grok__grok, mcp__grok__grok-reply, mcp__claude-review__review, mcp__claude-review__review_reply, mcp__claude-review__review_start, mcp__claude-review__review_reply_start, mcp__claude-review__review_status
> **Before each reviewer slot**, follow [Selectable Reviewers](../shared-references/reviewer-backends.md): > resolve invocation → `.aris/reviewer.json` → Claude Code default (Codex MCP) > with `reviewer_route.py` through the canonical helper resolver, preserving this > slot's tier, fresh contexts, source/image inputs and deterministic gates. > Codex examples/pins below apply only to `backend=codex`; other routes use their > own first-call/reply contract. Save the route and actual returned identity; > unavailable selections are `REVIEW_UNAVAILABLE`. Classify acceptance from actual > families/completion/scope. Forward invocation reviewer/model/effort overrides > to reviewer-bearing children. Generation workers are unchanged.
> 🔒 **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**
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.
| 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.
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.
· · · · · · · · 💬 Join Community · 🌱 ARIS is a methodology, not a platform. What matters is the research workflow — take it wherever you go.
Use when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.
Quick single-paper lookup via AlphaXiv LLM-optimized summaries with tiered source fallback. Use when user says "explain this…
Analyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says "analyze results",…
Search, download, and summarize academic papers from arXiv. Use when user says "search arxiv", "download paper", "fetch arxiv",…
Autonomously improve a generated paper via GPT-6-Astra xhigh review → implement fixes → recompile, for 2 rounds. Use when user…
Autonomous research review loop using any OpenAI-compatible LLM API. Configure via llm-chat MCP server or environment variables.…
Direct browser control via CDP for web interaction: automation, scraping, testing, screenshots, and site/app work. Also covers…
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling…