agentleFS
BESSER-PEARLBESSER-PEARL/research-agent-skills/research-paper-review/SKILL.md

research-paper-review

Skill18 starsChanged 4 months agoMITView on GitHub

Review and analyze academic research papers. Use this skill when the user asks to review a paper, analyze a publication, summarize research, critique methodology, extract key findings, compare papers, check for numerical inconsistencies, or assess novelty and contributions of academic work. Also triggers when the user mentions reading a PDF of a paper, wants a literature review, asks about related work, or wants to improve a paper before submission.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. GSA-TTS/devCrew_s1★ 51same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If target venue and/or the type of paper are provided, include them as context for all subsequent steps:

    line 33
  2. Distinctive:

    If the paper type is unknown, ask the user (or state the assumption you are reviewing under) before applying validation criteria.

    line 47
  3. Very specific:

    PDF: Use the Read tool with the pages parameter for large documents (max 20 pages per request).

    line 55
  4. Very specific:

    LaTeX source: Read the main .tex file first.

    line 56
  5. Very specific:

    Multiple files: Use Glob with /*.tex to find all source files, then read them in logical order (main file → sections → appendix).

    line 57
  6. Distinctive:

    Numbers across text, tables, and figures: Do values reported in the text match what's in the tables?

    line 76
  7. Distinctive:

    Statistical consistency: Do p-values, confidence intervals, and effect sizes align?

    line 77
  8. Distinctive:

    Calculations: Verify percentages, averages, sums.

    line 78
  9. Distinctive:

    Internal references: Do all \ref, \cite, figure/table references resolve?

    line 79
  10. Distinctive:

    Citations: Do all citations exist? Is citation style uniform (i.e.

    line 82
  11. Distinctive:

    Write down a list of the top 10 most immediate actions that the author should address.

    line 113
  12. Distinctive:

    Use this template for the review:

    line 120

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Research Paper Review

Assist researchers in reviewing, analyzing, and criticizing academic papers systematically and thoroughly.

When to Use

  • User asks to review, summarize, or critique a research paper
  • User shares a PDF or link to an academic paper
  • User wants to assess methodology, contributions, or novelty
  • User needs help writing a peer review
  • User wants to compare multiple papers or do a literature survey
  • User wants to improve a paper before submission (pre-submission review)
  • User wants to check for numerical/statistical inconsistencies
  • User wants venue-specific feedback (conference, journal, or preprint)

Inputs

  • Paper content: PDF, LaTeX source, or plaint text
  • Target Venue (optional but recommended): conference, journal, or preprint target - Example: "Models 2026", "TOSEM", "Sosym", "arXiv preprint"
  • Type of paper (important — ask the user if not provided): the review criteria change substantially by type. Common types: "full research" paper, "short" paper, "new ideas"/vision paper, "tool demo" paper, "poster", "extended abstract"/"short abstract", "journal"/"extended" paper. If the user does not state the type, ask before reviewing (or state the assumed type explicitly in the review).
  • Explicit reviewing guidelines (optional): if available provide a description or URL with the reviewing criteria.

Review Workflow

###Step 0: Pre-Processing / Venue Context

  • If target venue and/or the type of paper are provided, include them as context for all subsequent steps:

“Review this paper as if it is intended for [TARGET VENUE] as a [TYPE PAPER] submission. Consider typical standards, expectations, page limits, scope, and audience for this venue and type of paper”

  • Calibrate expectations to the paper type. Do not apply full-paper standards to every submission. In particular, do not fault a paper for missing something its type does not require (e.g., do not criticize a tool demo paper for lacking a real-world validation study, or a vision paper for lacking large-scale experiments). Use the table below as the baseline, then adjust with the venue's own guidelines:
Paper typePrimary evaluation focusValidation expectedCommon pitfalls to flag / not flag
Full research / journal (extended)Novelty, soundness, significance, completenessStrong, thorough empirical or theoretical validation; complete related work; reproducibilityFlag weak/absent validation, thin related work, non-reproducible results
Short paperA single focused, sound contributionPreliminary but credible validation; scope intentionally narrowFlag if the core claim is unsupported; do not flag limited scope or lack of exhaustive experiments
New ideas / vision paperNovelty, potential impact, clarity of the ideaConceptual argument or early evidence; full validation not requiredFlag vague or unmotivated ideas; do not flag absence of experiments
Tool demo paperUsefulness, maturity, architecture, availability, a clear demo scenarioDemonstration of the tool working; strong empirical/user validation is not requiredFlag unclear tool value, no availability/reproducibility of the tool, missing demo walkthrough; do not flag lack of a real-world evaluation study
Poster / extended abstract / short abstractClarity of the idea and early-stage promiseMinimal; preliminary results at mostFlag unclear framing; do not flag limited depth, short related work, or minimal evaluation
  • If the paper type is unknown, ask the user (or state the assumption you are reviewing under) before applying validation criteria.
  • Optional: Use the provided reviewing guidelines or try to find them on the venue website (if available) with standards for methodology, novelty, empirical rigor, validation and formatting. Venue-specific guidelines override the defaults above.

Step 1: Read the Paper

Identify the format and read accordingly:

  • PDF: Use the Read tool with the pages parameter for large documents (max 20 pages per request).
  • LaTeX source: Read the main .tex file first. Look for \input{} or \include{} commands to find additional sections, figures, and bibliography files. Use Grep to search for key commands like \begin{abstract}, \section, \cite across all .tex files.
  • Multiple files: Use Glob with **/*.tex to find all source files, then read them in logical order (main file → sections → appendix).

In all cases, skim the abstract, introduction, and conclusion first to get the big picture before diving into details.

Step 2: Structured Summary

Show that you understand the paper by producing a summary covering:

  1. Problem Statement — What problem does the paper address? Why does it matter?
  2. Contributions — What are the claimed contributions? (list them)
  3. Approach/Methodology — How do the authors solve the problem?
  4. Key Results — What are the main findings/metrics?
  5. Limitations — What are the acknowledged (and unacknowledged) limitations?

Step 3: Numerical & Consistency Checks - most info from linkedin

This is where LLM-assisted review adds the most value, catching things humans easily miss during manual review. Run these checks systematically:

  • Numbers across text, tables, and figures: Do values reported in the text match what's in the tables? Do figures reflect the data described?
  • Statistical consistency: Do p-values, confidence intervals, and effect sizes align? Are sample sizes consistent throughout?
  • Calculations: Verify percentages, averages, sums. Check that reported improvements (e.g., "30% improvement") match the actual numbers.
  • Internal references: Do all \ref, \cite, figure/table references resolve? Are there dangling references or wrong numbering?
  • Acronyms: Are all acronyms defined on first use?
  • Terminology consistency: Is the same concept always referred to with the same term?
  • Citations: Do all citations exist? Is citation style uniform (i.e. all conference papers are cited using the same fields, same for other venues)

Even minor errors (typos, broken references, wrong numbering) matter. reviewers often use these as signals that the paper was not carefully prepared.

Step 4: Critical Analysis

Evaluate the paper on these dimensions, weighting them according to the paper type (see the calibration table in Step 0). For example, weight Reproducibility and Soundness heavily for a full/journal paper, but weight Significance (tool usefulness, availability, demo clarity) more than exhaustive Soundness for a tool demo, and Novelty/Clarity over Soundness for a vision paper. When a dimension is not applicable to the paper type, say so explicitly rather than penalizing the paper for it.

DimensionQuestions to Answer
NoveltyIs this genuinely new? How does it differ from prior work?
SoundnessIs the methodology rigorous? Are experiments well-designed?
SignificanceDoes this advance the field meaningfully?
ClarityIs the paper well-written and well-structured?
ReproducibilityCould someone replicate this work from the paper alone?
Related WorkIs the positioning against prior work fair and complete?
Venue AlignmentDoes the paper meet expectations of the target venue (scope, depth, format, length, contribution type)?

Step 5: Provide Actionable Feedback

Structure feedback as:

  • Strengths — What the paper does well (be specific, cite sections)
  • Weaknesses — What could be improved (be constructive, suggest fixes)
  • Questions for Authors — Things that need clarification
  • Minor Issues — Typos, formatting, citation issues, broken references
  • Venue-Specific Recommendations — Highlight alignment issues, potential improvements to meet venue expectations

Step 6: Start here

Write down a list of the top 10 most immediate actions that the author should address.

These should be the ones that will bring the best "bang for the buck", i.e. actions that generate the most benefit relative to the cost of implementing them.

Output Format

Use this template for the review:

# Paper Review: [Title]

## Summary
[2-3 paragraph summary]

## Strengths
- S1: ...
- S2: ...

## Weaknesses
- W1: ...
- W2: ...

## Questions for Authors
- Q1: ...

## Minor Issues
- ...

## Venue-Specific Recommendations
- V1: ...
- V2: ...

## Overall Assessment
[1 paragraph verdict: accept/revise/reject with justification]

## Top actions . Start here
- T1: ...
- T2: ...


## Confidence
[Your confidence level in this review: low/medium/high, and why]

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.