Agent skill

paper-rebuttal

Guides writing effective rebuttals after receiving peer review feedback. Covers review diagnosis (score-driven color-coding), response strategy (champion identification, common-theme consolidation), tactical writing (18 rules), and counterintuitive rebuttal principles. Use when: user received reviewer scores/comments, needs to write a rebuttal or author response, wants to respond to specific criticism (e.g. 'limited novelty', 'missing baselines'), mentions 'rebuttal', 'reviewer comments', 'author response', or 'respond to reviewers'. Do NOT use for pre-submission self-review (use paper-review instead).

Stars 141
Forks 17

Install this agent skill to your Project

npx add-skill https://github.com/EvoScientist/EvoSkills/tree/main/skills/paper-rebuttal

Metadata

Additional technical details for this skill

tags
core writing academic-writing peer-review
author
EvoScientist
version
1.0.0

SKILL.md

Paper Rebuttal

A systematic approach to writing rebuttals after receiving peer review feedback. The goal is not to defend every point — it's to move scores by addressing the concerns that actually drive them.

When to Use This Skill

  • User received reviewer comments and needs to write a rebuttal
  • User asks how to respond to specific reviewer criticism
  • User wants to analyze reviews strategically before responding
  • User mentions "rebuttal", "reviewer comments", "review feedback", "respond to reviewers"

For pre-submission self-review and catching weaknesses before they become reviewer complaints, use the paper-review skill.

Step 1: Diagnose Reviews

Before writing a single word, answer: "Why did this reviewer give this exact score?" Not what they wrote — what drove the score. Most researchers skip this and address every comment equally. That is a mistake.

Score Diagnosis

For each reviewer, ask: "What would move this reviewer from their current score to acceptance?"

Score Range Typical Situation Your Strategy
7+ Already your champion Arm them with ammunition for the discussion phase
5-6 On the fence, 1-2 concerns holding them back Identify and resolve those specific concerns
3-4 Fundamental objection Determine if the objection is addressable; if not, focus elsewhere

Color-Code Every Comment

Read through each review and mark every comment:

Color Meaning Action Budget
Red Score-driving concern — this is why the score is low Address first, maximum effort and evidence 60%
Orange Addressable concern — can be resolved Respond with concrete data or revision 30%
Gray Minor or cosmetic Acknowledge briefly, confirm fix 10%
Green Positive comment or praise Note as ammunition for your champion

Identify the Invisible Question

Behind every reviewer comment is an unspoken question. A comment like "The baselines are outdated" really asks: "Is this method actually competitive with current approaches?" Address the invisible question, not just the surface request.

Step 2: Plan Response Strategy

Categorize Every Concern

Category Response Strategy
Misunderstanding Clarify with specific references to the paper; restate the key point
Missing experiment Provide the experiment inline if feasible; otherwise explain constraints honestly
Missing baseline Add comparison or explain precisely why the baseline is not applicable
Writing clarity Acknowledge and provide revised text in the rebuttal
Fundamental concern Address directly with technical arguments AND additional evidence
Minor issue Thank the reviewer and confirm the fix

Identify Common Themes

If multiple reviewers raise the same concern, it's almost certainly a real weakness. Consolidate these into a "Common Response" section — this saves word count and demonstrates that you understand the pattern.

Distinguish Actionable vs. Subjective

  • Actionable: "Missing comparison with Method X" — you can do this
  • Subjective: "The novelty is limited" — harder to address, but can be reframed with evidence

The Champion Strategy

Your rebuttal's real audience is not the negative reviewer — it's the positive one.

Your champion argues on your behalf in the AC discussion, often using your exact words. Write your rebuttal to arm them:

  1. Make key arguments copy-pasteable — your champion will quote you directly
  2. Highlight where reviewers agree with each other — consensus strengthens the champion's position
  3. Flag contradictions between reviewers — if R1 says "limited novelty" but R2 says "interesting approach," your champion can use this
  4. Lead with strengths before weaknesses — remind the AC what your paper does well

See references/rebuttal-tactics.md for the full 18 tactical rules.

Step 3: Write the Rebuttal

Structure

  1. Opening: One line thanking reviewers (keep it short)
  2. Common concerns: Address issues raised by multiple reviewers first — these are highest priority
  3. Per-reviewer responses: Address remaining concerns in priority order (red → orange → gray), NOT in the order the reviewer wrote them

Per-Concern Format

For each concern, follow this three-part structure:

  1. Acknowledge: Show you understand the concern (one sentence)
  2. Respond: Provide your answer — evidence, clarification, new experiment results
  3. Action: State what you changed in the revision (specific section/table/figure)

Use a fillable template at assets/rebuttal-template.md.

The Neutral Third-Party Test

Before submitting, have someone who hasn't read your paper read only the reviews and your rebuttal. Ask: "Can you tell whether the concerns were addressed?" If not, rewrite.

Counterintuitive Rebuttal Principles

  1. Submit a rebuttal even with extreme scores. A paper with scores of 3/8/8 has better odds than you think. The negative reviewer may realize they are an outlier during discussion. But only if you submit a rebuttal — without one, the AC has nothing to work with.

  2. Concede something small, win something big. Acknowledging a minor weakness ("We agree that Table 2 could include dataset X for completeness") makes your defense of major points more credible. Pure defense with zero concession reads as unobjective.

  3. One new experiment beats three paragraphs of explanation. Reviewers are trained to be skeptical of arguments. They are not trained to be skeptical of data. A small new experiment that directly addresses a concern is worth more than any amount of reasoning.

  4. The best rebuttal is written before submission. Draft responses to likely attacks while writing the paper ("prebuttal"). Two benefits: you often realize the attack is valid and fix the paper, and if the attack comes, you have a polished response ready.

  5. Don't defend every point equally. Equal effort signals you don't know which points matter. Allocate your word budget according to the color-coding: 60% red, 30% orange, 10% gray. Reviewers notice when you nail the big issues.

Common Reviewer Concerns

Prepare responses for these frequent concerns. Having a prepared response doesn't mean copying it verbatim — adapt to your specific paper and the reviewer's specific framing.

Common Concern Response Strategy
"Limited novelty" Articulate the specific insight; show what prior work cannot do; narrow and sharpen the claim
"Marginal improvement" Emphasize other advantages (speed, generalizability, simplicity); add challenging test cases
"Missing ablations" Provide the ablation table inline in the rebuttal
"Missing baselines" Add the comparison or explain precisely why it's not applicable
"Not reproducible" Add implementation details; commit to code release with a specific timeline
"Limited evaluation" Add diverse datasets or metrics; if infeasible, explain resource constraints honestly
"No limitation discussed" Add a limitation section in the revision; acknowledge this was an oversight
"Overclaimed results" Weaken specific claims to match evidence; show the revised wording
"Unfair comparison" Use standard evaluation protocols; add commonly reported baselines
"Method is engineering, not research" Identify the scientific insight behind the design; explain why the choice is non-obvious
"Metrics don't match claims" Align each claim with a specific metric; add the missing metric if feasible
"Related work incomplete" Add the missing references; explain the relationship to your work

Need to run new experiments for the rebuttal? Use the experiment-craft skill for targeted debugging, or experiment-pipeline for a full new experiment stage.

Handoff from Paper Review

This skill picks up where paper-review leaves off. If you used paper-review before submission, these artifacts are especially useful for rebuttal:

Artifact from paper-review How It Helps Rebuttal
Reject-first simulation You've already anticipated likely attacks
Claim-evidence audit table Quickly verify whether a reviewer's concern about unsupported claims is valid
Prebuttal drafts (Phase 6) Ready-made response templates for common criticisms
Trust scorecard Identifies weaknesses you can proactively concede

Reference Navigation

Topic Reference File When to Use
18 tactical rules rebuttal-tactics.md Detailed writing guidance for structure, content, tone
Rebuttal template rebuttal-template.md Starting a new rebuttal document

Expand your agent's capabilities with these related and highly-rated skills.

EvoScientist/EvoSkills

paper-writing

Guides writing academic papers section by section using an 11-step workflow with LaTeX templates and counterintuitive writing tactics. Covers Abstract, Introduction, Method, Experiments, Related Work, Conclusion, and Supplementary. Use when: user asks to write or draft a paper section, needs LaTeX templates, wants to improve academic writing quality, optimize novelty framing, or mentions 'write introduction', 'draft method', 'paper writing'. Do NOT use for pre-submission review (use paper-review), experiment execution (use experiment-pipeline), or paper planning/story design (use paper-planning).

141 17
Explore
EvoScientist/EvoSkills

evo-memory

Manages persistent research memory across ideation and experimentation cycles. Maintains two stores: Ideation Memory M_I (feasible/unsuccessful directions) and Experimentation Memory M_E (reusable strategies for data processing, model training, architecture, debugging). Three evolution mechanisms: IDE (after idea-tournament), IVE (after experiment failure — classifies failures as implementation vs fundamental), ESE (after experiment success — extracts reusable strategies). Use when: updating memory after completing idea tournaments or experiment pipelines, classifying why a method failed (implementation vs fundamental failure), starting a new research cycle needing prior knowledge, user mentions 'update memory', 'classify failure', 'what worked before', 'research history', 'evolution'. Do NOT use for running experiments (use experiment-pipeline), debugging experiment code (use experiment-craft), or generating ideas (use idea-tournament).

141 17
Explore
EvoScientist/EvoSkills

paper-navigator

End-to-end academic paper workflow: disambiguate queries, discover papers (search, citation traversal, recommendations, arXiv monitoring, trending, GitHub search), evaluate (TLDR, citations, code, SOTA), read with structured analysis (3-level strategy), and organize into literature maps or reports. Use when: finding papers, reading a paper, related work, literature survey, citation analysis, research trends, SOTA results, datasets, or literature reports. Do NOT use for writing a literature review section (use paper-writing), comparing research ideas (use idea-tournament), or planning paper structure (use paper-planning).

141 17
Explore
EvoScientist/EvoSkills

paper-review

Guides self-review of YOUR OWN academic paper before submission with adversarial stress-testing. Core method: 5-aspect checklist (contribution sufficiency, writing clarity, results quality, testing completeness, method design), counterintuitive protocol (reject-first simulation, delete unsupported claims, score trust, promote limitations, attack novelty), reverse-outlining, and figure/table quality checks. Use when: user wants to self-review or self-check their own paper draft before submission, stress-test their claims, prepare for reviewer criticism, or mentions 'self-review', 'check my draft', 'is my paper ready'. Do NOT use for writing a peer review of someone else's paper, and do NOT use after receiving actual reviews (use paper-rebuttal instead).

141 17
Explore
EvoScientist/EvoSkills

experiment-craft

Use this skill when the user wants to debug, diagnose, or systematically iterate on an experiment that already exists, or when they need a structured experiment log for tracking runs, hypotheses, failures, results, and next steps during active research. Apply it to underperforming methods, training that will not converge, regressions after a change, inconsistent results across datasets, aimless experimentation without progress, and questions like 'why doesn't this work?', 'no progress after many attempts', or 'how should I investigate this failure?'. Also use it for setting up practical experiment logging/record-keeping that supports debugging and iteration. Do not use it for designing a brand-new experiment pipeline or full experiment program (use experiment-pipeline), generating research ideas, fixing isolated coding/syntax errors, or writing retrospective summaries into research memory/notes/knowledge bases.

141 17
Explore
EvoScientist/EvoSkills

experiment-pipeline

Guides structured 4-stage experiment execution with attempt budgets and gate conditions: Stage 1 initial implementation (reproduce baseline), Stage 2 hyperparameter tuning, Stage 3 proposed method validation, Stage 4 ablation study. Integrates with evo-memory (load prior strategies, trigger IVE/ESE) and experiment-craft (5-step diagnostic on failure). Use when: user has a planned experiment, needs to reproduce baselines, organize experiment workflow, or systematically validate a method. Do NOT use for debugging a specific experiment failure (use experiment-craft) or designing which experiments to run (use paper-planning).

141 17
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results