/rebuttal-self-review

name: rebuttal-self-review
description: Systematic quality check for a completed rebuttal document before submission. Use after Stage 3 document compilation or after Stage 5 final remarks writing to verify completeness, tone, factual accuracy, and structural integrity. Catches common rebuttal errors before they reach reviewers.
tags: [Rebuttal, Quality, Review, Pre-Submission]
version: 1.0.0
source: Adapted from Claude Scholar (https://github.com/Galaxy-Dawn/claude-scholar), skills/paper-self-review/SKILL.md.

Rebuttal Self-Review

> **RebuttalStudio Utility — Pre-Submission Check** > Run this skill after Stage 3 or Stage 5 document generation, before copying the final text into OpenReview or the submission portal. It catches structural gaps, tone issues, and factual risks that stage-specific skills may have missed.

A systematic quality assurance checklist tailored for academic conference rebuttals (ICLR, ICML, NeurIPS, and similar venues).

---

Overview

Unlike a paper, a rebuttal has a strict deadline, tight word limits, and must directly engage with specific reviewer concerns. This review process is optimized for those constraints: fast, targeted, and submission-ready focused.

**Recommended timing:**

• After Stage 3 compilation (before first-round submission)
• After Stage 5 final remarks (before final remarks submission)
• After each multi-round Stage 4 response (optional but recommended)

---

Review Checklist

1. Coverage — Did You Address Everything?

The most common rebuttal failure is missing a reviewer concern.

Coverage Check:
- [ ] Count the total issues in Stage 1 breakdown for each reviewer
- [ ] Confirm each issue appears in the Stage 3 document
- [ ] For multi-round reviewers, confirm each follow-up was answered
- [ ] No reviewer's comment was silently dropped
- [ ] If an issue was not addressed, a reason is stated ("We will address this in the revision")

2. Tone — Is It Collaborative, Not Defensive?

Tone Check:
- [ ] Opening of each reviewer section thanks the reviewer
- [ ] No response uses defensive phrases ("The reviewer is wrong", "This criticism is unfounded")
- [ ] Disagreements are framed as clarifications ("We believe this may be due to…")
- [ ] Commitments are grounded ("We will add X in Section Y" not "We might consider…")
- [ ] No sarcasm or frustration, even with persistent or unfair reviews

3. Factual Accuracy — No Fabrication

Factual Check:
- [ ] All cited results match the actual paper numbers
- [ ] No experiment is claimed that was not actually run
- [ ] No citation is mentioned that has not been verified (see citation-verification skill)
- [ ] "Changes made" pointers (section/table/figure numbers) are accurate
- [ ] No comparison results were invented to satisfy a reviewer

4. Structure — Is It Easy to Navigate?

Conference rebuttals are read quickly. Structure affects perceived quality.

Structure Check:
- [ ] Each reviewer has a clearly labeled section
- [ ] Each concern has a visible label matching the Stage 1 breakdown title
- [ ] Quoted reviewer text appears before each response (using the Stage 2 format)
- [ ] The document reads in a logical order: per-reviewer, then per-issue
- [ ] For Stage 5: section headers (Acknowledgments / Key Strengths / Key Concerns / Commitment) are present

5. Clarity — Would a Tired Reviewer Understand It?

Clarity Check:
- [ ] Each response states its conclusion in the first sentence
- [ ] Technical claims are self-contained (no unexplained jargon for new terms)
- [ ] Tables are labeled and readable without surrounding text
- [ ] Formulas use consistent notation with the paper
- [ ] No response is longer than needed (trim to the minimum convincing length)

6. Writing Quality — Does It Sound Human-Authored?

Writing Check:
- [ ] No AI filler phrases ("It is worth noting that…", "Furthermore…" as opener)
- [ ] Sentence lengths are varied
- [ ] Claims are specific to this paper (not generic statements)
- [ ] If in doubt, apply writing-anti-ai skill to the full document

---

Review Process

Follow these steps for a systematic pass:

**Pass 1 — Coverage scan (5 min)** > Count all Stage 1 atomic issues. Open the Stage 3 document. Check off each issue.

**Pass 2 — Tone pass (10 min)** > Read only the opening sentence of each response. Does each one feel collaborative? Fix any that don't.

**Pass 3 — Factual spot-check (10 min)** > Pick 3–5 specific claims (percentages, section numbers, citation names). Verify them against the paper.

**Pass 4 — Structure skim (5 min)** > Can you navigate from one reviewer to another, and one issue to another, in 30 seconds? If not, improve headings.

**Pass 5 — Final read-aloud (optional)** > Read the document aloud or use text-to-speech. Awkward phrases become obvious when heard.

---

Common Rebuttal Errors

| Error Type | Description | How to Fix | |-----------|-------------|-----------| | Silent skip | An issue has no response | Add even a one-sentence placeholder | | Over-promising | "We will completely redesign Section 4" | Scope it: "We will add a clarifying paragraph to Section 4" | | Unverified citation | Citing a paper you haven't confirmed exists | Apply citation-verification skill | | Wrong pointer | "See Table 3" but the data is in Table 2 | Verify all section/figure/table references | | Defensive pivot | Reframing the concern without addressing it | Address it directly first, then provide context | | Invisible result | "We ran this experiment" with no numbers | Include the result or say "results will appear in the revision" |

---

After the Review

Once all checks pass:

1. **For Stage 3**: Copy the compiled document to the submission portal. Respect word/character limits. 2. **For Stage 5**: Copy the final remarks to the final remarks box. 3. **Keep a local copy**: The project.json autosaves, but export a Markdown backup before submitting.

---

*Adapted from Claude Scholar