/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:
$ npx -y skills add evoscientist/evoskills --skill paper-rebuttal --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/paper-rebuttal
Context preview
The summary Claude sees to decide when to auto-load this skill.
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:
SKILL.md
paper-rebuttal.SKILL.mdname: paper-rebuttal
description: "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)."
allowed-tools: "write_file edit_file read_file think_tool"
metadata:
author: EvoScientist
version: '1.0.0'
tags: [core, writing, academic-writing, peer-review]
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](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](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
Read more
name: paper-rebuttal description: "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)." allowed-tools: "write_file edit_file read_file think_tool" metadata: author: EvoScientist version: '1.0.0' tags: [core, writing, academic-writing, peer-review]
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](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](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
The official skill repository for EvoScientist. Each skill is an installable knowledge pack that extends EvoScientist with domain-specific expertise.
Other skills on evoskills.
- /academic-slides
Use this skill for creating or refining an academic slide deck and the talk built around it: structuring a conference talk, thesis defense, lab meeting, or paper-to-slides deck; deciding the narrative arc and slide breakdown; improving slide design and visual hierarchy; planning
Open skill - /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
Open skill - /evomath-tao
Use this skill whenever the user submits a non-trivial mathematical claim that needs a rigorous proof or audit. Trigger on IMO/Putnam/USAMO/Olympiad-style problems, ML/AI theoretical statements, research conjectures, suspected-false claims, multi-step proofs the user already
Open skill - /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
Open skill - /experiment-iterative-coder
Iterative code refinement through plan → code → evaluate → refine cycles. Runs lint checks (ruff), tests (pytest), and structured self-evaluation each cycle, then diagnoses failures and refines. Decomposes complex tasks into sequential phases, iterates up to 3 times per phase
Open skill - /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
Open skill

