Token导航 LogoToken导航

Agent Skill · 研究检索

paper-review(论文评审)

paper-review 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

paper-review 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 18,964。

总安装 5,832周安装 243GitHub Stars 346下载 1,944核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:paper-review(论文评审)
来源仓库:https://github.com/evoscientist/evoskills
仓库路径:skills/paper-review
安装命令:
npx skills add https://github.com/evoscientist/evoskills --skill paper-review
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/evoscientist/evoskills --skill paper-review

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

paper-review 提供系统性五方面评审清单,包括反向提纲构建、图表质量检查及答辩准备指导。适用于提交前自检论文完整性、结构清晰度或准备应对审稿人质疑的场景。覆盖论点逻辑、证据充分性、格式规范等多个维度,帮助提升学术写作质量。使用时需结合具体论文内容逐项核对,避免遗漏关键缺陷点。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/paper-review

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/evoscientist/evoskills --skill paper-review;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

paper-review 怎么安装?

在终端执行 npx skills add https://github.com/evoscientist/evoskills --skill paper-review。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

paper-review 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

paper-review 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

paper-review 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

paper-review 用的人多吗?

公开数据是累计安装 5,832 次,近一周安装 243 次,下载 1,944 次,GitHub 346 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

paper-review 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
paper-review

论文评审 · 本页

5,832346只读未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

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


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?
  • Datasets too simple? Do the benchmarks truly test the method's capabilities?
  • No failure case analysis? Honest failure analysis increases credibility.

Red flag: Missing ablations or baselines is one of the most common reasons for rejection.

Aspect 5: Method Design Issues

Experimental setting is impractical; method has technical flaws; method is not robust; new method's costs outweigh its benefits.
  • Impractical experimental setting? Are assumptions realistic for the intended use case?
  • Technical flaws? Does the method have theoretical or conceptual weaknesses?
  • Not robust? Does the method require per-scene hyperparameter tuning?
  • Benefit < Limitation? Does the new module introduce limitations that outweigh its benefits?

Red flag: If the method requires significant tuning per scenario, add robustness experiments or acknowledge and address the limitation.


Critical Reminder: Claims Must Have Support

Every claim in the paper (especially in the Abstract and Introduction) must be correct and supported by experiments. Some reviewers will reject a paper directly for unsupported claims.

Go through every claim in the Abstract and Introduction. For each claim:

  • Is it factually correct?
  • Is there an experiment or analysis that supports it?
  • Is the supporting experiment clearly referenced?

An unsupported claim — especially in the Abstract or Introduction — can be grounds for rejection.


Reverse-Outlining Technique

Extract the writing plan from finished paragraphs and check whether the flow is smooth.

After writing a section (or the entire paper):

  1. Read each paragraph one at a time
  2. Write down the main message of each paragraph in one sentence
  3. Read the sequence of messages — does it flow logically?
  4. Identify breaks: Where does the flow feel abrupt or illogical?
  5. Fix: Reorganize paragraphs, add transitions, or split/merge paragraphs

Apply this to:

  • Introduction (check narrative flow)
  • Method (check if modules are presented in logical order)
  • Experiments (check if results are presented in a meaningful sequence)

Figure and Table Quality Checklist

Figures

  • Pipeline figure highlights novelty (not just explanation)
  • Pipeline figure looks distinct from prior work
  • Teaser figure is compelling and self-contained
  • All figures have clear captions
  • Resolution is high enough for print
  • Color-blind friendly (avoid red-green only distinctions)
  • Figures are referenced in the text

Tables

  • Captions are above the table
  • No vertical lines
  • Using booktabs (\toprule, \midrule, \bottomrule)
  • Best results highlighted (bold/color)
  • Metric direction indicated (↑/↓)
  • Captions describe setup/notation, not results
  • All tables are referenced in the text

Conclusion and Limitation Check

  • Conclusion summarizes contributions and key results
  • Limitation section is present (reviewers frequently flag its absence)
  • Limitations are about task/setting scope (like future work), not technical defects Rule: "If our method does not fall below SOTA metrics, it is not a technical defect"
  • Limitations are honest but not self-defeating

Pre-Submission Final Checks

  • All references are complete (no "?" or missing entries)
  • Author information matches venue requirements
  • Page count is within limits
  • Supplementary material is properly referenced
  • No TODO markers remain in the paper
  • Acknowledgments section is appropriate
  • No accidental double-blind violations (for anonymous review)
  • All cited works have complete bibliographic entries (authors, title, venue, year)
  • No self-citations that break anonymity (for double-blind venues)
  • Key related works cited — missing a prominent baseline paper can trigger rejection

Handoff to Rebuttal

When reviews come back, use the paper-rebuttal skill for:

  • Score diagnosis and review color-coding
  • Champion strategy (arming your positive reviewer for discussion)
  • 18 tactical rules for structure, content, and tone
  • Counterintuitive rebuttal principles

Your self-review artifacts (reject-first simulation, claim-evidence audit, prebuttal drafts from the counterintuitive protocol) feed directly into the rebuttal process.


See references/review-checklist.md for an expanded version of the 5-aspect checklist with more detailed sub-questions.

For adversarial stress testing and reject-risk thresholds, see references/counterintuitive-review.md.

平台分布

Codex

35.88%
按下载量换算698

Claude

32.64%
按下载量换算635

Cursor

17.11%
按下载量换算333

Gemini CLI

10.05%
按下载量换算195

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills