academic-slides
Use this skill for creating or refining an academic slide deck and the talk built around it:…
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.
/paper-rebuttalContext 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:
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]
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.
> For pre-submission self-review and catching weaknesses before they become reviewer complaints, use the `paper-review` skill.
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.
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 |
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 | — |
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.
| 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 |
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.
**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.
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
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).
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.
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.
Use this skill for creating or refining an academic slide deck and the talk built around it:…
Manages persistent research memory across ideation and experimentation cycles. Maintains two…
Use this skill whenever the user submits a non-trivial mathematical claim that needs a…
Use this skill when the user wants to debug, diagnose, or systematically iterate on an…
Iterative code refinement through plan → code → evaluate → refine cycles. Runs lint checks…
Guides structured 4-stage experiment execution with attempt budgets and gate conditions:…