/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,
$ npx -y skills add evoscientist/evoskills --skill paper-review --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-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.mdname: 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
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?
- [ ] *
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

