/aris-rebuttal

name: aris-rebuttal
description: "Workflow 4: Submission rebuttal pipeline. Parses external reviews, enforces coverage and grounding, drafts a safe text-only rebuttal under venue limits, and manages follow-up rounds. Use when user says \"rebuttal\", \"reply to reviewers\", \"ICML rebuttal\", \"OpenReview response\", or wants to answer external reviews safely."
argument-hint: "[paper-path-or-review-bundle]"
allowed-tools: Bash(*), Read, Grep, Glob, Write, Edit, Agent, Skill, mcp__codex__codex, mcp__codex__codex-reply
license: MIT
metadata:
  author: wanshuiyin/ARIS
  version: "1.0.0"

Workflow 4: Rebuttal

Prepare and maintain a grounded, venue-compliant rebuttal for: **$ARGUMENTS**

Scope

This skill is optimized for:

• ICML-style **text-only rebuttal**
• strict **character limits**
• **multiple reviewers**
• **follow-up rounds** after the initial rebuttal
• safe drafting with **no fabrication**, **no overpromise**, and **full issue coverage**

This skill does **not**:

• run new experiments automatically
• generate new theorem claims automatically
• edit or upload a revised PDF
• submit to OpenReview / CMT / HotCRP

If the user already has new results, derivations, or approved commitments, the skill can incorporate them as **user-confirmed evidence**.

Lifecycle Position

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   auto-review-loop (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

Constants

• **VENUE = `ICML`** — Default venue. Override if needed.
• **RESPONSE_MODE = `TEXT_ONLY`** — v1 default.
• **REVIEWER_MODEL = `gpt-5.4`** — Used via Codex MCP for internal stress-testing.
• **MAX_INTERNAL_DRAFT_ROUNDS = 2** — draft → lint → revise.
• **MAX_STRESS_TEST_ROUNDS = 1** — One Codex MCP critique round.
• **MAX_FOLLOWUP_ROUNDS = 3** — per reviewer thread.
• **AUTO_EXPERIMENT = false** — When `true`, automatically invoke `/aris-experiment-bridge` to run supplementary experiments when the strategy plan identifies reviewer concerns that require new empirical evidence. When `false` (default), pause and present the evidence gap to the user for manual handling.
• **QUICK_MODE = false** — When `true`, only run Phase 0-3 (parse reviews, atomize concerns, build strategy). Outputs `ISSUE_BOARD.md` + `STRATEGY_PLAN.md` and stops — no drafting, no stress test. Useful for quickly understanding what reviewers want before deciding how to respond.
• **REBUTTAL_DIR = `rebuttal/`**

> Override: `/aris-rebuttal "paper/" — venue: NeurIPS, character limit: 5000`

Required Inputs

1. **Paper source** — PDF, LaTeX directory, or narrative summary 2. **Raw reviews** — pasted text, markdown, or PDF with reviewer IDs 3. **Venue rules** — venue name, character/word limit, text-only or revised PDF allowed 4. **Current stage** — initial rebuttal or follow-up round

If venue rules or limit are missing, **stop and ask** before drafting.

Safety Model

Three hard gates — if any fails, do NOT finalize:

1. **Provenance gate** — every factual statement maps to: `paper`, `review`, `user_confirmed_result`, `user_confirmed_derivation`, or `future_work`. No source = blocked. 2. **Commitment gate** — every promise maps to: `already_done`, `approved_for_rebuttal`, or `future_work_only`. Not approved = blocked. 3. **Coverage gate** — every reviewer concern ends in: `answered`, `deferred_intentionally`, or `needs_user_input`. No issue disappears.

Workflow

Phase 0: Resume or Initialize

1. If `rebuttal/REBUTTAL_STATE.md` exists → resume from recorded phase 2. Otherwise → create `rebuttal/`, initialize all output documents 3. Load paper, reviews, venue rules, any user-confirmed evidence

Phase 1: Validate Inputs and Normalize Reviews

1. Validate venue rules are explicit 2. Normalize all reviewer text into `rebuttal/REVIEWS_RAW.md` (verbatim) 3. Record metadata in `rebuttal/REBUTTAL_STATE.md` 4. If ambiguous, pause and ask

Phase 2: Atomize and Classify Reviewer Concerns

Create `rebuttal/ISSUE_BOARD.md`.

For each atomic concern:

• `issue_id` (e.g., R1-C2)
• `reviewer`, `round`, `raw_anchor` (short quote)
• `issue_type`: assumptions / theorem_rigor / novelty / empirical_support / baseline_comparison / complexity / practical_significance / clarity / reproducibility / other
• `severity`: critical / major / minor
• `reviewer_stance`: positive / swing / negative / unknown
• `response_mode`: direct_clarification / grounded_evidence / nearest_work_delta / assumption_hierarchy / narrow_concession / future_work_boundary
• `status`: open / answered / deferred / needs_user_input

Phase 3: Build Strategy Plan

Create `rebuttal/STRATEGY_PLAN.md`.

1. Identify 2-4 **global themes** resolving shared concerns 2. Choose **response mode** per issue 3. Build **character budget** (10-15% opener, 75-80% per-reviewer, 5-10% closing) 4. Identify **blocked claims** (ungrounded or unapproved) 5. If unresolved blockers → pause and present to user

**QUICK_MODE exit**: If `QUICK_MODE = true`, stop here. Present `ISSUE_BOARD.md` + `STRATEGY_PLAN.md` to the user and summarize: how many issues per reviewer, shared vs unique concerns, recommended priorities, and evidence gaps. The user can then decide to continue with full rebuttal (`/aris-rebuttal — quick mode: false`) or write manually.

Phase 3.5: Evidence Sprint (when AUTO_EXPERIMENT = true)

**Skip entirely if `AUTO_EXPERIMENT` is `false` — instead, pause and present the evidence gaps to the user.**

If the strategy plan identifies issues that require new empirical evidence (tagged `response_mode: grounded_evidence` with `evidence_source: needs_experiment`):

1. Generate a mini experiment plan from the reviewer concerns:

• What to run (ablation, baseline comparison, scale-up, condition check)
• Success criterion (what result would satisfy the reviewer)
• Estimated GPU-hours

2. Invoke `/aris-experiment-bridge` with the mini plan:

   /aris-experimen