Review Response

Review Response

Systematic workflow for responding to reviewer comments on academic papers. Covers the full cycle from parsing comments through to a polished rebuttal document.

When to Use

• "Help me write a rebuttal"
• "Respond to reviewer comments"
• "Handle this R&R"
• "Develop a review response strategy"
• Paper has received referee reports and needs a structured response

Workflow

1. Receive reviewer comments
2. Parse and classify each comment (Major / Minor / Typo / Misunderstanding)
2b. Re-audit the paper against its artifact (empirical papers)
3. Develop response strategy per comment (Accept / Defend / Clarify / Experiment)
4. Write structured responses
5. Tone check — every response must pass the tone checklist
6. Assemble final rebuttal document

Step 1: Parse and Classify

Read all reviewer comments and classify each one:

Keyword signals for classification:

• Major: "major concern", "fundamental issue", "missing experiments", "insufficient evidence", "not convincing"
• Minor: "minor concern", "could be improved", "please clarify", "suggestion"
• Typo: "typo", "grammar", "formatting", "inconsistent"
• Misunderstanding: "The authors did not..." (but they did), "It is unclear..." (but it is stated)

Priority order: Major > Misunderstanding > Minor > Typo

Present the full classification table to the user before proceeding to strategy.

Step 1b: Re-audit the paper against its artifact (empirical papers)

Before assigning any strategy, check the submitted paper against the code, the run outputs and the replication package. Reviewers see the artifact too. A rebuttal that defends a claim the artifact contradicts does more damage than the original error.

• Every reviewer claim about the artifact. Check each one directly against the files (model, framework, environment, "the code does not do X"). Classify it as reviewer-correct, reviewer-misread or ambiguous in the paper, with file:line evidence.
• Qualitative methods claims. Check the paper's descriptions of tools, models, what was logged, procedures performed and pre-registration status against the code and artifacts. Treat protocol or plan documents as the source of those claims, never as evidence for them.
• Headline numbers. Recompute them from the saved outputs, and spot-read the raw records behind any extraction or matching step (parsers, path or ID normalisers). Treat any anomaly a reviewer points to, or any count that looks too convenient, as a lead to follow.

If the re-audit finds a genuine error, stop and present it to the user before drafting, with the corrected figures and the claims that no longer hold. Whether and how to disclose it is his decision. When the audit was prompted by a reviewer's scrutiny, credit that scrutiny without implying the reviewer found the error. Trigger incident: 2026-09-23 ICSE #1402. A re-audit prompted by one reviewer's code inspection found a result-changing bug and four protocol-vs-implementation drifts that 25 logged pre-submission review passes (12 distinct checks) had missed.

Step 2: Develop Response Strategy

For each classified comment, assign a strategy:

Decision flow:

Comment → Is the reviewer correct?
  Yes → Is the fix feasible?
    Yes → Accept
    No  → Accept principle + explain constraint + offer alternative
  Partially → Accept valid part + Defend the rest with evidence
  No (misunderstanding) → Clarify with specific location references
  Requests new work → Is it feasible?
    Yes → Experiment
    No  → Explain limitation + offer alternative analysis

Strategy combinations (common in practice):

• Accept + Clarify: "We agree and have expanded Section 3. We also note this was partially addressed in Table 2."
• Defend + Experiment: "Our choice of X is justified because [reasons], but we have also added the comparison with Y as requested."

Full strategy library with templates: references/response-strategies.md

Step 3: Write Responses

Each response follows this structure:

**Comment N.M**: [Reviewer's original comment, quoted verbatim]

**Response**: [Our substantive reply]

**Changes**: [Specific modifications with section/page/table references]

Non-negotiable rules:

1. Every comment gets a response — even typos
2. Every response starts with thanks
3. Every claim in the response has evidence (data, citation, or specific manuscript reference)
4. Every change states its location (Section X, page Y, Table Z)
5. Never say "The reviewer is wrong" — use "We would like to respectfully clarify"
6. Every "Changes:" entry is verified against the manuscript before the letter is assembled — read/grep the actual .tex at the cited location; never trust the comment tracker, an earlier letter draft, or memory of the edit. A promised change with no matching manuscript edit is either downgraded to an honest acknowledgment ("we discuss rather than change...") or flagged to the user as unfulfilled — a letter must never describe the manuscript as more revised than it is. Record the outcome per commitment in the tracker's Fulfillment Ledger (fulfilled / partial / not_fulfilled / acknowledgment_only; see templates/referee-comments/comment-tracker.md).