/inno-rebuttal

name: inno-rebuttal
description: Drafting and refining academic rebuttals for top-tier AI/CS conferences (NeurIPS, ICML, ICLR, CVPR, ECCV, AAAI, ARR, KDD, UAI, AISTATS, TMLR, etc.). Use this skill whenever the user needs to respond to reviewer comments, write a rebuttal, handle reviewer feedback, clarify technical misunderstandings, present additional experimental results, or deal with borderline accept/reject decisions. Also trigger when the user mentions keywords like "rebuttal", "reviewer", "review response", "author response", "camera-ready", "rebut", "AC", "area chair", "meta-review", or discusses conference review scores. Trigger for Chinese-language requests too, e.g. "写rebuttal", "回复审稿人", "审稿意见", "rebuttal怎么写", "reviewer说我的baseline不够".
allowed-tools: Read Write Edit Bash
license: MIT license
metadata:
    skill-author: K-Dense Inc.

Academic Rebuttal Drafting and Refinement

Overview

A rebuttal is a venue-constrained response workflow, not just a writing task. The goal is to clarify misunderstandings, resolve decision-relevant concerns, convert review analysis into an actionable task list, and produce the correct submission artifact for the target venue.

This skill supports multiple end states depending on what the user needs:

• review analysis only,
• analysis plus prioritized task list,
• task list plus paper edit plan,
• full venue-specific rebuttal draft,
• final pre-submission verification.

Handling Inputs

Reviews arrive in many formats. Before starting analysis:

• **Pasted text**: Use directly. Ask the user to confirm whether the paste is complete.
• **PDF reviews**: Read the PDF and extract all review text, scores, and confidence levels.
• **Screenshots**: Read the image and transcribe all visible review content. Flag any truncated or unclear sections.
• **OpenReview / CMT links**: Ask the user to paste the review text, since external platform access is unreliable.
• **LaTeX source or paper PDF**: Read as needed to cross-reference claims reviewers question.

If reviews are incomplete (e.g., missing scores or confidence), ask the user before proceeding.

Routing First

Before drafting anything, determine the venue and route the workflow using `references/venue_rule_matrix.md`.

Primary routing dimensions:

1. **Artifact structure**: one-page PDF rebuttal, per-review response, threaded discussion, rolling review / revision plan, or single-feedback response. 2. **Revision policy**: revised manuscript allowed during discussion, not allowed, or unclear (use conservative handling). 3. **Policy constraints**: anonymity, external links, new experiments, confidential AC channel, LLM disclosure requirements.

If the venue is unknown or only partially confirmed, state that explicitly and choose the most conservative workflow.

---

Rebuttal Workflow

Run the workflow in stages. Do not force a user confirmation pause after every stage unless the user asked for a checkpoint or the next step is risky.

Stage 1: Review Analysis, Classification, and Issue Board

Analyze all reviews to identify core themes, major technical "deal-breakers," and common questions.

**Key Actions:**

• **Extract a Score Matrix:** Create a table listing Reviewer ID, scores, confidence, and a short summary of each review's decision logic.
• **Classify Reviewer Stance:** Label each reviewer as Champion (score >= 7, positive language), Persuadable (score 4-6, mixed), or Entrenched (score <= 3, strong negative). This guides effort allocation — invest most in converting Persuadable reviewers while maintaining Champion support. See `references/writing_principles.md` for stance-based tone guidance.
• **Identify Decision-Critical Concerns:** Combine low scores, high confidence, repeated concerns across reviewers, and likely AC-facing issues.
• **Group Common Concerns:** Identify points raised by multiple reviewers (e.g., [R1, R3] both ask about Baseline X).
• **Categorize Issues:** Distinguish between soundness, novelty, significance, clarity, missing baselines, missing ablations, theory gaps, limitations, ethics, and minor edits.
• **Assign Severity:** Use the following classification for each concern:

| Severity | Definition | |---|---| | **Major-Blocking** | Can single-handedly cause rejection (methodology flaws, novelty challenges) | | **Major-Addressable** | Significant but resolvable with evidence or targeted revision | | **Minor** | Clarity, formatting, typos — low decision weight | | **Misunderstanding** | Reviewer missed existing content in the paper |

• **Identify "The AC's Perspective":** What will an Area Chair see as the main reason to accept or reject?

**Output: Issue Board**

Build a structured Issue Board tracking every atomized concern. For single-reviewer or purely-minor scenarios, a simpler table suffices.

issue_id | reviewer | severity          | category   | strategy | status
R1-1     | R1       | Major-Blocking    | baselines  | (TBD)    | open
R1-2     | R1       | Minor             | clarity    | (TBD)    | open
R2-1     | R2       | Misunderstanding  | novelty    | (TBD)    | open
R2-2     | R2       | Major-Addressable | ablations  | (TBD)    | open
R3-1     | R3       | Major-Addressable | baselines  | (TBD)    | open  [shared with R1-1]

Update the `strategy` and `status` columns as you progress through subsequent stages. Before finalizing (Stage 5), every Major-Blocking and Major-Addressable issue must reach status=done.

See `references/issue_board_guide.md` for the full schema, a worked example, and cross-review consistency checking.

If the user requested only analysis, stop here. Otherwise continue to Stage 2.

Stage 2: Strategy Selection

For each issue on the board, select one or more response strategies. The right strategy depends on whether the reviewer's point is factually correct and how much it affects the acceptance decision.

| Strategy | When to use | Example | |---|---|---| | **Accept and fix** | The reviewer is right, and the f