Academic Rebuttal Drafting

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:

• 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 Combinations

Real concerns often need compound strategies. Common combos:

• Clarify + Accept partial: "We already address X in Section 3.2, but we agree the presentation was unclear. We have rewritten the paragraph and added a clarifying figure."
• Accept + New evidence: "We agree this baseline was missing. We have now run the comparison — results in the table below show our method outperforms by 2.1%."
• Partial agree + Scope narrow: "We agree the claim is too broad for the non-stationary case. We have narrowed Theorem 2 to the stationary setting and added this as a limitation."

See references/response_strategies.md for detailed templates, full worked examples, and tone before/after comparisons.

Key Principles:

• Be Direct: Answer the core question in the first sentence.
• Evidence Over Promises: Prefer actual evidence. If evidence is missing, convert that gap into a concrete task rather than hand-waving.
• Professional Tone: Avoid defensive phrasing.
• Venue Awareness: Do not suggest new experiments, new figures, revised PDFs, or external links unless the venue rules support them.

Output: Update the Issue Board with the chosen strategy for each issue.

Stage 3: Task List Synthesis

Convert the strategy map into an actionable task list.

Typical task types:

• rerun or add an experiment
• collect a missing baseline number
• extract evidence already present in the paper
• rewrite an unclear claim
• soften an overclaim
• add a limitation
• prepare a confidential AC note
• compress a draft to fit venue limits

For each task, record: owner if known, required input, expected output, whether it must happen before drafting, whether it changes the manuscript, the rebuttal only, or both.

If the user asked for planning plus execution, carry out the feasible tasks before drafting.

Stage 4: Draft the Correct Artifact

Compose the full rebuttal, respecting conference-specific formats. Select the output structure from the venue router in references/venue_rule_matrix.md:

• One-page PDF rebuttal (CVPR, ICCV, ECCV): short summary, merged high-impact concerns, only the most decision-relevant reviewer-specific points.
• Per-review response (ICML, KDD): one response block per review, direct answer first, then evidence.
• Threaded discussion (ICLR, NeurIPS, UAI, AISTATS): concise opening, reply to concrete questions, keep follow-ups easy.
• Rolling review (ARR, TMLR): response now plus revision plan for the next manuscript version.
• Single-feedback (AAAI, The Web Conference): prioritize issues most likely to affect committee discussion.

Character Budget (for venues with explicit limits)

When the venue imposes a character or word limit, allocate the budget before writing:

For example, with ICML's 5000-character limit: ~600 chars opener, ~4000 chars per-reviewer, ~400 chars closing. Verify the final count with scripts/count_limits.sh.

When the venue has no explicit limit, skip budgeting.

Dual Output

Produce two versions of every rebuttal:

1. Paste-ready version: Plain text (or minimal markdown) that fits directly into the venue's submission form (OpenReview, CMT, EasyChair). Stripped of formatting the platform does not support. Verified against character limits with scripts/count_limits.sh.
2. Extended version: Full markdown with complete evidence tables, internal cross-references, and author notes marked with [INTERNAL]. This is the team's working copy for review before submission.

Generate the extended version first, then strip it down for the paste-ready copy.

Formatting:

• Use [R1], [R2], etc., for reviewer IDs.
• Use bolding or headers for key themes (e.g., Novelty:, Baselines:).
• Use "Q/A" format only when it fits the venue and saves space.
• Keep responses self-contained: include the key clarification or result in the response itself.

Example of a good response to a reviewer concern:

[R2] Missing comparison to MethodX

We appreciate this suggestion. We have added a comparison to MethodX on all three benchmarks. As shown below, our method outperforms MethodX by 2.3% on CIFAR-100 and 1.8% on ImageNet-1K, while being 1.5x faster at inference:

Method	CIFAR-100	ImageNet-1K	Inference (ms)
MethodX	82.1	79.4	12.3
Ours	84.4	81.2	8.1

We have updated Table 2 in the revised manuscript.

Example of a bad response (avoid this):

We believe the reviewer failed to notice that our method is clearly superior. We will add the comparison in the camera-ready.

The bad version is defensive ("failed to notice"), provides no evidence, and makes an empty promise.