Skip to content
Research
Skill

/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,

From plugin
evoskills
42516 skills
Install
$ npx -y skills add evoscientist/evoskills --skill paper-review --agent claude-code

How 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-review

Context preview

The summary Claude sees to decide when to auto-load this skill.

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,

SKILL.md

paper-review.SKILL.md
name: paper-review
description: "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). Also runs as a background expert: dispatch it async with a draft path and it reviews end-to-end while you keep working."
allowed-tools: "read_file edit_file write_file think_tool"
metadata:
  author: EvoScientist
  version: '1.1.0'
  type: [skill, expert]
  tags: [core, writing, academic-writing, peer-review]

Paper Review

A systematic approach to self-reviewing academic papers before submission. Covers a 5-aspect review checklist, reverse-outlining for structural clarity, figure/table quality checks, and rebuttal preparation.

When to Use This Skill

  • User wants to review or check a paper draft before submission
  • User asks for feedback on paper quality or completeness
  • User wants to prepare for potential reviewer criticism
  • User mentions "review paper", "check my draft", "self-review"

> If the user has already received reviewer comments and needs to write a rebuttal, use the `paper-rebuttal` skill instead.

Prerequisites

Before starting review, confirm the `paper-writing` handoff checklist is satisfied: all sections drafted, claims anchored to evidence, limitation section present, figures finalized, and no unresolved `\todo{}` markers. If any item is incomplete, finish writing before reviewing.

---

The Perfectionist Approach

> Strive for perfection: review your own paper, consider every question a reviewer might ask, and address them one by one.

The best defense against negative reviews is a thorough self-review: 1. **Adversarial review**: Read your own paper as a critical reviewer would 2. **Seek advisor feedback**: Ask your advisor to review — the more feedback, the better 3. **Address everything**: For every potential weakness you find, either fix it or prepare a defense

Counterintuitive Review Protocol

Run this protocol before final polishing:

1. **Reject-first simulation**: Force yourself to write a one-paragraph reject summary before writing any positive comments. 2. **Delete one unsupported strong claim**: If a strong claim lacks direct evidence, remove it instead of defending it. 3. **Score trust, not only score gains**: Papers with slightly lower gains but higher fairness and reproducibility often receive better review outcomes. 4. **Promote one explicit limitation**: Move one meaningful limitation from hidden notes into the paper; transparency can increase confidence. 5. **Attack your novelty claim**: Ask "Could a strong PhD derive this in one afternoon?" If yes, narrow and sharpen the novelty statement.

See [references/counterintuitive-review.md](references/counterintuitive-review.md)

---

5-Aspect Self-Review Checklist

Aspect 1: Contribution Sufficiency

> The paper does not provide readers with new knowledge.

Ask these questions to evaluate whether the contribution is sufficient:

  • [ ] **Are the failure cases common?** If the failure cases are frequent and obvious, reviewers may question whether the method is ready for publication.
  • [ ] **Is the proposed technique well-explored?** If the technique is already widely studied, what new insight or improvement do we bring?
  • [ ] **Is the improvement foreseeable / well-known?** If the improvement was predictable from combining known ideas, the novelty may be questioned.
  • [ ] **Is the technique too straightforward?** A straightforward application of existing techniques may lack sufficient contribution.

**Red flag**: If "yes" to any of these, strengthen the contribution narrative or add more technical depth.

Aspect 2: Writing Clarity

> Missing technical details, not reproducible; a method module lacks motivation.

  • [ ] **Missing technical details?** Would a reader be able to reproduce the method from the paper alone?
  • [ ] **Missing module motivation?** Does every module in the Method section explain *why* it exists, not just *what* it does?
  • [ ] **Paragraph structure**: Does each paragraph have a clear topic? Does the first sentence state the point?
  • [ ] **Flow**: Is the logical flow between paragraphs and sections smooth?
  • [ ] **Terminology**: Are terms used consistently throughout?

**Red flag**: If reproducibility is in doubt, add implementation details or supplementary material.

Aspect 3: Experimental Results Quality

> Only slightly better than previous methods; or better than previous methods but still not good enough.

  • [ ] **Marginal improvement?** If the improvement over SOTA is very small, is it statistically significant?
  • [ ] **Absolute quality insufficient?** Even if better than baselines, is the output quality good enough for the application?
  • [ ] **Visual quality**: Do qualitative results look convincing? Are improvements visible?

**Red flag**: If improvements are marginal, emphasize other advantages (speed, generalizability, simplicity) or add more challenging test cases.

Aspect 4: Experimental Testing Completeness

> Missing ablation studies; missing important baselines; missing important evaluation metrics; data too simple.

  • [ ] **Missing ablation studies?** Is every core contribution ablated?
  • [ ] **Missing important baselines?** Are recent SOTA methods included?
  • [ ] **Missing evaluation metrics?** Are all standard metrics for this task reported?
  • [ ] *
Read more
Ships withevoskills

The official skill repository for EvoScientist. Each skill is an installable knowledge pack that extends EvoScientist with domain-specific expertise.

Get the whole plugin

Other skills on evoskills.