A rebuttal has two audiences. Reviewers have read the paper to varying depths and may have forgotten or misread details. The Area Chair (AC) knows even less about the paper and may read only the reviews and your response. The goal is to clarify and persuade both—and most importantly, to make it easy for the AC to decide (Parikh, Batra & Lee). A useful test: a neutral third party should be able to judge from the rebuttal alone whether each concern has been addressed, without opening the paper or the reviews.
At ICML (2026 rules; please check .icml/venue_facts.md): three rounds of discussion (author response, reviewer follow-up, author follow-up), each round limited to 5000 characters; no revised PDF may be uploaded during the response period; no non-anonymous, personal, or shortened URLs (reviewers are not required to click links anyway); no need to answer every minor point; organize by reviewer ID; stay professional. For accepted papers, the reviews and the full discussion will be public, and reviewers will write a post-rebuttal note stating whether you addressed their concerns.
Communicate with the user in the user's language; write the response in English.
Basic rules
- Do not fabricate results. You may design experiments and write code to run them. But you must not write numbers into the response before the experiments have finished running and the values have been written to a file. Experiments that have not been run should be honestly described as not yet run.
- Humans decide strategy. What to concede, what to argue, whether to run the experiments reviewers requested, and whether to raise an unfair review with the AC are all author decisions. Prepare options; do not decide for the authors.
- Never proactively accuse reviewers of malice. If the authors want to flag a review that ignores the paper or lacks basis, help them express it factually and politely, preferably through a confidential comment to the AC if the platform allows it.
- Stay anonymous. No names, affiliations, identifying links, or "our previous work X." Only anonymous repositories, and only when useful (reviewers do not need to open them).
- The response must also not contain any hidden content or guidance text aimed at reviewer models.
- Do not promise—deliver. Since a revised PDF cannot be uploaded, put the actual new text, numbers, or proof sketches directly into the response, and note that these will be added to the paper. Write every commitment into
.icml/rebuttal/promises.md。
Step 0 — Preparation
Run python scripts/init_workspace.py --root <latex-root> --skill icml-rebuttal. Save each review as .icml/reviews/R-<reviewerID>.md(including scores), and also save any meta-review/AC message if present. Read .icml/claims.md、state.md, any earlier simulated reviews (which often predicted the issues), and the paper itself. If the workspace does not exist, note in state.md that the ledger is missing, and verify numbers directly from the paper and results files.
Step 1 — Item-by-item triage (classification table)
Build .icml/rebuttal/triage.md, with one row per independent comment (following references/rebuttal-playbook.md §2): ID (R1.3), direct quote of the core review comment, type (misunderstanding / already in paper / missing experiment / missing baseline / clarity / overclaim / related work / reviewer factual error / minor / out of scope), severity of impact on the decision, which reviewers share the concern, possible response, available evidence (paper location, ledger number, whether a new experiment is needed), owner.
Then summarize for the user: each reviewer's score and confidence; the 2–4 concerns that actually affect the decision; shared concerns; issues that are easy to resolve; where the paper is genuinely weak. Be honest — a rebuttal cannot solve everything, and pretending otherwise wastes a precious time window.
Step 2 — Decision (human checkpoint)
Propose a strategy and wait for the authors to confirm:
- For each major concern: concede and correct, clarify, rebut with evidence, or acknowledge as a limitation, with your recommendation;
- additional experiments worth running within the time window, estimated cost, and what kind of result would be convincing (explicitly state that the result may go against the paper);
- what can be downplayed.
Record the decision in decisions.md。
Step 3 — Experiments (if any)
Write and run (or have the user run) the code; record the results to a file; add them to the claims ledger (as new numbers, marked as verified: yesonly when read from the output). Report negative or mixed results truthfully, and discuss with the authors how to present them. Reviewers and the AC reward transparency; hidden negative results surfacing later are far worse.
Step 4 — Draft the response
Follow references/rebuttal-playbook.md. Handle each reviewer separately, ordered by priority (address the biggest concerns you can answer best first):
- Open with a sentence of thanks, and mention any positive comments from the reviewer if there are any,
- Briefly quote the core of each concern, then useanswer directly in the first sentence("Yes, ...", "No, ...", "Not quite: ...", "We ran this: ..."), followed by evidence, then additional context,
- When the answer is already in the paper, point to the exact paper location and restate it so the response is self-contained,
- Answer the intent behind the question, not just its literal wording,
- Use data instead of argument wherever possible,
- End with what changes will be made in the paper.
Also draft a briefoverall response(if the platform/thread structure allows a comment visible to all reviewers and the AC): the strengths the reviewers agree on, the shared concerns and how they will be addressed, and a summary of new results. Make sure every part is within the character limit.
Step 5 — Check and finalize
Run python scripts/check_rebuttal.py .icml/rebuttal/round1/*.md --limit 5000 --names "..." --affils "...". It counts characters, flags URLs, identity strings, empty promises ("we will ...") without substance, aggressive wording, excessive apology, and unresolved placeholders. Then reread each response from the AC's perspective: is the answer to each major concern clear in the first line? Show the drafts to the user for approval before posting; the user posts them (do not submit on the user's behalf on OpenReview unless the user explicitly asks and the environment allows it).
Later rounds
For the author follow-up round: read the reviewers' follow-up comments, answer only the new content, acknowledge score changes graciously, and do not re-argue settled issues. If a reviewer did not participate in the discussion, a brief polite note reiterating the key concerns that have been addressed can help the AC.
After the decision
Keep promises.md updated; icml-camera-ready reads it and checks whether each promised revision has been implemented in the final version. If the paper is rejected, the classification table and commitments will become the revision plan for submitting to the next venue (icml-write).
Files
scripts/check_rebuttal.py— checks the rebuttal file for length, anonymity, and tone.scripts/init_workspace.py— shared workspace.references/rebuttal-playbook.md— principles, classification format, rebuttal patterns, wording, pitfalls.references/icml-venue-facts.md、references/workspace-contract.md— shared files.