paper-reading
Skill54 starsChanged 5 months agoMITView on GitHub
Deep, critical paper-reading workflow that produces a structured reading note. Use when the user wants to read, understand, summarize, break down, or take notes on a single research paper. English triggers: "read this paper", "read the paper", "paper reading", "paper notes", "deeply read", "critically read", "summarize this paper", "break down the paper", "explain this paper", "walk me through this paper", "help me understand this paper". Chinese triggers: "读论文", "精读论文", "理解论文", "拆解 论文", "整理论文笔记", "帮我看这篇论文", "分析这篇论文". Also triggers when the user hands over a .pdf, an arXiv URL or ID, or a paper title and asks for deep understanding. NOT for quick one-paragraph overviews (use alphaxiv), broad literature surveys (use research-lit), or simulated peer review (use mock-review).
20 other projects use a version of this.
Adopted by
Most recently taken up by
- crce-ux/paper-readingtheir own version, first seen Nov 8, 2026
- paratrooper-vincent/paper-readingtheir own version, first seen Nov 1, 2026
- xiaofengShi/paper-reading-skilltheir own version, first seen Oct 26, 2026
- jinxiy1104/Obsidian_Paper_Ingestion_Skilltheir own version, first seen Oct 20, 2026
- BH2-4/paper-craft-pipelinetheir own version, first seen Oct 20, 2026
- techdou/paper-readingtheir own version, first seen Oct 20, 2026
Other versions20 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 20
- voidful/academic-skills★ 126same name
- jxtse/scientific-research-skills★ 68same name
- Agentchengfeng/paper-reading-skills★ 28same name
- Kingslayer-bot/paper-reading-skill★ 28same name
- a1henu/paper-reading-skill★ 11same name
- xiaofengShi/paper-reading-skill★ 11same name
- Shen-An/learn-skill★ 5same name
- techdou/paper-reading★ 5same name
- JinukMoon/agent-skills★ 4same name
- luffysolution-svg/omnischolar★ 4same name
10 more not listed
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.
In this repository27 other files it gives its agents.
- alphaxivSkill
- arxivSkill
- doc-coauthoringSkill
- docxSkill
- drawio-diagramSkill
- figure-descriptionSkill
- formula-derivationSkill
- grant-proposalSkill
- mmx-cliSkill
- mock-reviewSkill
- novelty-checkSkill
- pdfSkill
- phd-benchmark-paper-templateSkill
- phd-figure-designerSkill
- phd-idea-evaluatorSkill
- phd-intro-drafterSkill
- phd-pre-submission-reviewerSkill
- phd-tech-paper-templateSkill
- phd-vibe-research-workflowSkill
- pptxSkill
- proof-writerSkill
- research-litSkill
- research-survey-loopSkill
- research-wikiSkill
- theme-factorySkill
- update-source-mapSkill
- xlsxSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
21 rules. 0 are common, 10 are distinctive, and 11 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Read the whole paper, including appendices.
- Distinctive: line 40
Read these bundled files in this order, before drafting the final note:
- Very specific: line 48
Use scripts when available.
- Distinctive: line 59
All output lives in the project that triggered the skill, not in the skill folder.
- Distinctive: line 63
Before downloading any PDF, resolve the project paper directory in this order:
- Very specific: line 65
If the user names a path (for example "save to references/papers/" or "save to my project's paper drive"), use that path verbatim.
- Very specific: line 101
If <project_root>/readings/ already exists with prior notes, append to it.
- Very specific: line 111
Run extract_text.py <paper.pdf> --output <working>/text/ to produce text/full.txt and text/pages.json.
- Very specific: line 112
Run split_sections.py <working>/text/ to produce text/sections.json.
- Distinctive: line 113
Read in this order: abstract, introduction, related work, experiments.
- Distinctive: line 114
Write a 1-paragraph "what is this paper about" and a 3-5 bullet list of the paper's claimed contributions.
- Distinctive: line 125
Read the original paper's abstract, introduction, and task definition section.
- Very specific: line 127
If a benchmark's original purpose and the way the paper uses it are mismatched, mark the row with mismatch: yes and note the original task …
- Distinctive: line 128
Do not silently accept the paper's framing.
- Very specific: line 146
Run render_pages.py <paper.pdf> --output <working>/pages/ to produce pages/page_NN.png and pages/pages.json (the sidecar that records the …
- Very specific: line 153
If a crop is bad, retry with --bbox "x,y,w,h" to specify the crop region manually in PNG pixels.
- Very specific: line 160
Use numbered citations [1], [2], ...
- Distinctive: line 164
Write the final note in the user's language: If the user asked in Chinese, write Chinese.
- Very specific: line 165
Before declaring done, run the self-check in references/output-contract.md.
- Very specific: line 169
Read references/critical-reading-checklist.md for the full set.
- Distinctive: line 173
Never write a claim without a citation.
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Paper Reading
Paper request: $ARGUMENTS
This skill produces a deep, critical, structured reading note for a single research paper. The note follows a fixed 9-section template, embeds cropped figures from the paper, cites every claim with a numbered reference, and links only to external sources. The final note is written in the same language the user used to invoke the skill unless the user explicitly asks for another language.
Core Boundary
This skill is a personal reading note tool, not a peer review, not a survey, not a quick lookup.
Rules:
- Read the whole paper, including appendices. A skim of abstract plus experiments is not a reading.
- Be objective and critical. Quote the paper, do not advertise it. Words like "groundbreaking", "novel", "amazing", "revolutionary" require verifiable evidence and are usually wrong.
- Every claim must be traceable: cite the section, figure, or table. Every cited paper must have been re-fetched and read in original, not relied on from a secondary summary.
- Crop figures, do not paste whole pages. A figure that occupies half a page and is mostly whitespace or another figure is not informative. Crop further to the region that carries the argument.
- Numbered citations
[1],[2], etc. The reference list at the end of the note contains only external links (arXiv, DOI, publisher page). No local file paths in the reference list. - All downloaded papers live in the project that triggered the skill, never inside this skill's folder. The skill folder is meant to be reusable across projects.
- The final note is in the user's language. Chinese question -> Chinese note. English question -> English note. Explicit specification -> that specification.
Required Resources
Read these bundled files in this order, before drafting the final note:
references/note-template.md- 9-section reading note structurereferences/benchmark-guard.md- how to verify that each benchmark actually tests what the paper claimsreferences/related-work-schema.md- columns to use inrelated_work_matrix.mdreferences/critical-reading-checklist.md- objective and critical reading rulesreferences/output-contract.md- non-negotiable output rules: citation style, figure policy, anti-patterns, self-check
Use scripts when available. Each script is self-contained and prints usage on --help:
scripts/extract_text.py- extract structured text from the PDF, with=== PAGE N ===markersscripts/split_sections.py- heuristic section splitter, writessections.jsonscripts/render_pages.py- render each PDF page to a PNG, writespages.jsonsidecar with the actual page-number widthscripts/locate_figures.py- find figure captions and crop the figure body from the rendered page
For page rendering, render_pages.py can also delegate to the pdf skill's converter script if that skill is installed alongside this one. In the standard skills-root layout, the delegate path is ../pdf/scripts/convert_pdf_to_images.py relative to this skill directory. If the installation layout differs, resolve the installed pdf skill directory first and pass its scripts/convert_pdf_to_images.py path to --delegate.
Working Directory Contract
All output lives in the project that triggered the skill, not in the skill folder. Output is split into two locations: human deliverable (the final reading note) and agent scratch (intermediate artifacts). Humans look at the first, the agent owns the second.
Project paper directory (REQUIRED)
Before downloading any PDF, resolve the project paper directory in this order:
- If the user names a path (for example "save to
references/papers/" or "save to my project's paper drive"), use that path verbatim. - Else, probe the current working directory for an existing paper directory in this order and use the first match:
papers/references/papers/docs/papers/
- Else, create
<cwd>/papers/and use it.
Record the resolved path in Phase 2 when filling benchmark_audit.md (each row has a local_path column). Never write PDFs into the skill folder.
Working layout
<project_root>/
├── papers/ <- resolved project paper directory
│ └── <author>__<year>__<slug>.pdf
├── readings/<paper-slug>/ <- HUMAN DELIVERABLE (visible to user)
│ ├── paper_note.md
│ └── figures/
│ └── figure_N.png
└── x_temp/paper-reading/<paper-slug>/ <- AGENT SCRATCH (intermediate only)
├── pages/ <- page_NN.png from render_pages.py
│ └── pages.json <- width sidecar (consumed by locate_figures.py)
├── figures/ <- scratch cropped figure_N.png + figure_N.meta.json
├── text/
│ ├── full.txt <- extract_text.py output
│ └── sections.json <- split_sections.py output
├── benchmark_audit.md <- Phase 2 output
└── related_work_matrix.md <- Phase 3 outputThe paper-slug is a filesystem-safe identifier derived from the paper title. Lowercase, alphanumerics and hyphens only.
Where the final note lives
The final paper_note.md lives in <project_root>/readings/<slug>/, not in x_temp/. x_temp/ is agent scratch space; humans do not look there. After Phase 5 synthesis, the agent must write paper_note.md to readings/<slug>/. Any cropped figures referenced by the final note must be copied into readings/<slug>/figures/ so the note stays self-contained. The audit (benchmark_audit.md) and matrix (related_work_matrix.md) stay in x_temp/paper-reading/<slug>/ because they are intermediate artifacts. Create the readings/<slug>/ and readings/<slug>/figures/ directories if they do not exist.
If <project_root>/readings/ already exists with prior notes, append to it. If the user names a different "human deliverable" path, use that path verbatim and skip the readings/ default.
Workflow
The workflow is five sequential phases. Do not skip phases. Do not run phases in parallel: each later phase depends on output from the earlier ones.
Phase 1: Skim and frame the problem
Goal: in plain words, what problem is this paper solving, and what is the problem class it belongs to?
- Run
extract_text.py <paper.pdf> --output <working>/text/to producetext/full.txtandtext/pages.json. - Run
split_sections.py <working>/text/to producetext/sections.json. - Read in this order: abstract, introduction, related work, experiments.
- Write a 1-paragraph "what is this paper about" and a 3-5 bullet list of the paper's claimed contributions. These are intermediate notes; they feed into Phase 5.
- Do not yet download benchmark or prior-art papers. Do not yet crop figures. This sub-step is for framing only.
- Read 2 foundational works to understand the problem class. Pick from the target paper's related work: one paper that defines the problem class the target paper belongs to (for example, for a VLA paper, RT-2 or OpenVLA), and one that introduces a key dataset or benchmark the target paper uses. Read abstract and introduction only — not the full paper. These two reads are what make §3 of the final note informative; without them, the agent can only paraphrase the target paper's introduction and the note's "what is this problem" section becomes empty.
Phase 2: Benchmark audit
Goal: verify that every benchmark the paper uses actually tests what the paper claims it tests. This guards against the common failure mode where a benchmark designed for task A is borrowed by a paper on task B without explanation.
For each benchmark named in the experiments section:
- Find or download the benchmark's original paper into the resolved project paper directory.
- Read the original paper's abstract, introduction, and task definition section. Skim the rest.
- Fill one row in
benchmark_audit.mdusing the schema inreferences/benchmark-guard.md. - If a benchmark's original purpose and the way the paper uses it are mismatched, mark the row with
mismatch: yesand note the original task vs the paper's task in the cell. - Do not silently accept the paper's framing. If the paper says "we use X for Y" but X was designed for Z, the note must say so.
A benchmark-mismatch warning must appear in paper_note.md section 7 if any row is flagged. See references/benchmark-guard.md for the full audit schema and worked examples.
Phase 3: Prior art and classic works
Goal: understand the lineage of ideas and identify the most classic prior work in the subfield.
- From the introduction's related work and the experiments' comparison tables, extract the set of papers the target paper directly compares against. Cap at 15 papers total for this phase. If the paper cites more, pick the 15 that are most central to the paper's claim. (A minimum of 5 keeps the matrix representative; fewer than 5 means the target paper has almost no direct baselines and the matrix will be thin.)
- Identify the 1-3 "most classic" works in this subfield (often older, highly-cited, foundational). These may or may not be in the comparison set; include them anyway.
- Download each into the project paper directory. Prefer, in order: arXiv, publisher OA, OpenReview, author website, project page. Do not bypass paywalls.
- For each, read abstract, introduction, and experiments. Do not read the full paper. The goal is to understand: what problem, what method, what result, why it matters in the lineage.
- Save one row per paper to
related_work_matrix.mdusing the columns defined inreferences/related-work-schema.md.
Phase 4: Deep read and figure capture
Goal: now that benchmarks and prior art are understood, re-read the entire paper carefully and capture every key figure as a cropped image.
- Run
render_pages.py <paper.pdf> --output <working>/pages/to producepages/page_NN.pngandpages/pages.json(the sidecar that records the actual page-number width). Use--dpi 150as a sensible default; bump to 300 if figure text is too small. - Re-read the paper from start to finish: method, experiments, limitations, conclusion, appendix. Earlier reading of benchmarks and prior art makes this re-read substantively deeper than the first skim.
- For each
Figure N,Table N, or other visually informative element that the note will reference, runlocate_figures.py <paper.pdf> --text-dir <working>/text/ --pages-dir <working>/pages/ --output <working>/figures/ --figure Nto producefigures/figure_N.pngplusfigures/figure_N.meta.json. - Visually QA every cropped figure immediately. Open the PNG and confirm:
- The crop contains the figure body, not just the caption or whitespace.
- The crop is not clipped at top, bottom, or sides.
- The figure is readable at note-zoom (text inside the figure is legible).
- If a crop is bad, retry with
--bbox "x,y,w,h"to specify the crop region manually in PNG pixels. Do not embed a broken figure into the note.
Phase 5: Synthesize the final note
Goal: produce a single paper_note.md that any reader (including the user, six months from now) can use to recall the paper's contribution and the reading session's verdict.
- Open
references/note-template.mdand follow the 9-section structure verbatim. Section order is fixed. - Use numbered citations
[1],[2], ... everywhere a paper, book, or report is referenced. Put the reference list at the end of the note; the list contains only external URLs. - Copy every figure that the final note embeds from
<working>/figures/into<project_root>/readings/<slug>/figures/, then insert the copied cropped figures in the section that references them, with. Never link to a whole-page render. Never point the final note atx_temp/. - Apply the rules in
references/output-contract.mdstrictly: numbered citations only, external links only in the reference list, no anachronistic critique, no "rather than" sentence pattern, no process narration in the final note. - Apply the rules in
references/critical-reading-checklist.md: every claim cites a section, figure, or table; numbers carry units and sample sizes; overclaims are flagged in-line; unevaluated scenarios are noted. - Write the final note in the user's language. If the user asked in Chinese, write Chinese. If in English, write English. The template's section labels can be translated. If the user explicitly specifies a language, use that.
- Before declaring done, run the self-check in
references/output-contract.md. If any item fails, fix and re-run.
Critical Reading Rules
Read references/critical-reading-checklist.md for the full set. The most important rule in one line:
Authors claim X. Evidence is at section Y / figure Z. Evidence supports claim: yes / no / partial. State the verdict in the note.
Never write a claim without a citation. Never write a number without units and sample size. Never write a critique from a later vocabulary that the early work could not have used. Flag every benchmark that the paper borrows from a mismatched original purpose.
Failure Handling
- PDF text extraction fails -> fall back to OCR via
pdftoppm+tesseractif available, otherwise ask the user for a text version. - Benchmark original paper cannot be legally obtained -> record the URL and the source gap in
benchmark_audit.md; do not silently treat absence as confirmation. - arXiv download fails -> try the publisher's HTML page, OpenReview, or the author's homepage. If none works, record the failure and continue.
- Figure auto-crop is wrong after one attempt -> re-run
locate_figures.pywith--bbox "x,y,w,h"to specify the crop manually in PNG pixels. Do not embed a broken figure. - A cited paper's external link is dead -> replace with the closest equivalent URL (publisher page, DOI resolver, arXiv abstract page) and note the change in the reference list.
- The user's request is ambiguous about which paper -> ask one concise question before downloading anything.
- The paper is in a language the user did not specify -> default to writing the note in that paper's language only if the user agrees.
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
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.

