agentleFS
marciobmarciob/skill-research-papers/research-papers/SKILL.md

research-papers

Skill7 starsChanged 6 months agoMITView on GitHub

Research, filter, compare, and synthesize scientific papers across arXiv, OpenAlex, ACM Digital Library, DBLP, Semantic Scholar, PubMed, SSRN, and publisher landing pages. Use when the agent needs to do literature discovery, find top or recent papers, build a reading list, compare methods or results, trace citation graphs, summarize evidence, or produce properly attributed paper recommendations and literature reviews.

  • Reads credentials

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.

    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

Show its rules and text

We split this skill into the rules it gives an agent

37 rules. About 0 are common, 33 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈33

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to turn broad paper-search requests into a defensible literature search and synthesis.

    line 19
  2. Distinctive:

    When executing API calls and web lookups, use whatever tools your platform provides:

    line 34
  3. Very specific:

    Shell / Bash / terminal: Use curl for *discovery* against research APIs (arXiv, OpenAlex, DBLP, Semantic Scholar, PubMed).

    line 37
  4. Distinctive:

    Web fetch: Use your platform's web fetch tool only for source pages the script does not handle (publisher search results, ACM landing …

    line 38
  5. Distinctive:

    Web search: Use your platform's web search tool for broad discovery when APIs are insufficient.

    line 39
  6. Distinctive:

    File read: Read the reference files in this skill directory for detailed guidance.

    line 40
  7. Distinctive:

    If the user asks for "top papers" without more detail, infer a balanced mix of:

    line 55
  8. Distinctive:

    Read source-guides.md when deciding where to search or which identifiers to keep.

    line 63
  9. Distinctive:

    Read api-playbook.md when the task requires live programmatic access to source metadata or search endpoints.

    line 64
  10. Distinctive:

    Read smoke-tests.md before claiming that a source currently works in a headless environment.

    line 65
  11. Distinctive:

    Start broad with OpenAlex or Semantic Scholar

    line 69
  12. Distinctive:

    Use DBLP to clean up computer science metadata and venue names

    line 70
  13. Distinctive:

    Use ACM Digital Library for canonical ACM records

    line 71
  14. Distinctive:

    Use PubMed for biomedical and life-science topics

    line 72
  15. Distinctive:

    Use arXiv for frontier or preprint-heavy areas

    line 73
  16. Distinctive:

    Use SSRN for economics, law, finance, and social-science working papers

    line 74
  17. Distinctive:

    Prefer canonical paper landing pages over search-result snippets whenever possible.

    line 76
  18. Distinctive:

    Prefer official public APIs over HTML scraping whenever they exist.

    line 77
  19. Distinctive:

    Treat ACM Digital Library and SSRN as web sources first unless the user provides a private integration, because this skill does not assume …

    line 78
  20. Distinctive:

    Keep a short search log of the query variants that returned the strongest results.

    line 92
  21. Distinctive:

    If no full-text source is found, mark the paper as abstract-only.

    line 119
  22. Distinctive:

    Use multiple sources in parallel when possible.

    line 121
  23. Distinctive:

    Read screening-rubric.md when ranking or comparing papers.

    line 131
  24. Distinctive:

    Keep papers that are:

    line 133
  25. Distinctive:

    Never imply that arXiv or SSRN papers are peer reviewed unless publication status is verified.

    line 147
  26. Very specific:

    If parsed_lines is missing from the JSON (older cached parses created before this protocol existed), re-run with --force to regenerate it.

    line 177
  27. Distinctive:

    Use judgment, not a rule: Read figures whose content matters to the synthesis question:

    line 188
  28. Distinctive:

    Always read figures cited by name in a passage you are about to summarize ("as shown in Figure 3, …").

    line 190
  29. Distinctive:

    Read figures whose captions describe quantitative results, benchmarks, ablations, or schematics central to the method.

    line 191
  30. Very specific:

    When caption_nearby is false and size_kb is small (under ~5KB), it is often an inline equation render or sub-component — read it only if …

    line 193
  31. Distinctive:

    If you still want to try a specific URL the cascade missed (e.g., an author homepage), pass the URL directly:

    line 203
  32. Very specific:

    If the script returns status: "abstract_only" or failed, surface that clearly in the output and explain which steps were tried (from the …

    line 224
  33. Distinctive:

    Read output-shapes.md when the user wants a shortlist, literature review, comparison table, or research brief.

    line 232
  34. Distinctive:

    Start with the conclusion or recommendation

    line 236
  35. Distinctive:

    If the evidence base is thin, conflicting, or very recent, say so directly.

    line 244
  36. Distinctive:

    If a paper was found through an index but the full text was not accessed, label the synthesis as metadata-based.

    line 246
  37. Distinctive:

    Every substantial response should include:

    line 260

≈ “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 Papers

Overview

Use this skill to turn broad paper-search requests into a defensible literature search and synthesis. Start broad, narrow with explicit criteria, prefer stable landing pages and full text when available, and separate discovery metadata from evidence claims.

Full-text reading is the default, not the exception. For every shortlisted paper, you MUST attempt to fetch and read the entire paper content — every page from title to references — not just the abstract or introduction. Download PDFs when HTML full text is unavailable. Only fall back to abstract-based analysis when all full-text access methods have been exhausted and failed.

The script that does the fetch (scripts/fetch_and_parse) gives you two mechanical aids so the agent cannot skip content by accident: a chunked read_plan listing every Read call needed to cover the file, and an END-OF-PAPER:<sha> sentinel at the very end of the parsed file. You must execute every entry in read_plan and you must quote back the matching sentinel before producing any synthesis. Skipping either is a protocol violation.

Common requests this skill should handle:

  • Find the top papers on a topic
  • Build a reading list for a new area
  • Compare seminal papers with recent work
  • Summarize the evidence behind a method or claim

Tool Guidance

When executing API calls and web lookups, use whatever tools your platform provides:

  • Full-text fetch + parse (canonical path): Use the scripts/fetch_and_parse helper. It resolves any identifier (DOI, arXiv ID, PMID, PMCID, URL), runs the OA cascade, downloads the PDF/HTML/XML, and writes a layout-aware Markdown rendering you can read with the harness Read tool. Output is cached at ~/.cache/research-papers/, so repeat invocations on the same paper are free.
  • Shell / Bash / terminal: Use curl for discovery against research APIs (arXiv, OpenAlex, DBLP, Semantic Scholar, PubMed). Once you have an identifier, switch to fetch_and_parse for the full text — do not hand-roll PDF downloads or pass raw PDFs through the Read tool.
  • Web fetch: Use your platform's web fetch tool only for source pages the script does not handle (publisher search results, ACM landing pages).
  • Web search: Use your platform's web search tool for broad discovery when APIs are insufficient.
  • File read: Read the reference files in this skill directory for detailed guidance.

Workflow

1. Frame the research question

Identify:

  • Topic and subtopic
  • Domain
  • Time window
  • Desired output shape
  • Whether the user wants seminal work, recent work, or both
  • Whether preprints are acceptable

If the user asks for "top papers" without more detail, infer a balanced mix of:

  • Seminal or highly influential work
  • Strong recent work
  • Directly relevant surveys or review papers

2. Choose search sources

Read source-guides.md when deciding where to search or which identifiers to keep. Read api-playbook.md when the task requires live programmatic access to source metadata or search endpoints. Read smoke-tests.md before claiming that a source currently works in a headless environment.

Default source strategy:

  • Start broad with OpenAlex or Semantic Scholar
  • Use DBLP to clean up computer science metadata and venue names
  • Use ACM Digital Library for canonical ACM records
  • Use PubMed for biomedical and life-science topics
  • Use arXiv for frontier or preprint-heavy areas
  • Use SSRN for economics, law, finance, and social-science working papers

Prefer canonical paper landing pages over search-result snippets whenever possible. Prefer official public APIs over HTML scraping whenever they exist. Treat ACM Digital Library and SSRN as web sources first unless the user provides a private integration, because this skill does not assume a stable public API for them.

3. Build a query set

Expand the user topic into:

  • Synonyms
  • Acronyms
  • Older terminology
  • Benchmark or dataset names
  • Method names
  • Domain constraints
  • Exclusion terms when noise is high

Keep a short search log of the query variants that returned the strongest results.

4. Gather candidate papers

Unless the user wants a quick shortlist, collect roughly 15 to 30 candidate papers before deep screening.

For each paper, capture:

  • Title
  • Authors
  • Year
  • Venue or publication status
  • DOI, PMID, arXiv ID, or SSRN ID when available
  • Stable URL
  • Abstract or summary
  • Source used to find it
  • Citation or influence indicators if available
  • Full-text URL (if resolved)
  • Full-text format: HTML, PDF, or XML
  • Full-text source: arXiv HTML, PMC, OpenAlex OA, Semantic Scholar OA, SSRN, or DOI landing

Resolve full-text access

For each paper, attempt to resolve a full-text URL using the cascade in api-playbook.md:

  1. arXiv HTML → arXiv PDF → PMC XML → PMC HTML → OpenAlex OA → Semantic Scholar OA → SSRN page → DOI landing
  2. Record which step succeeded and what format the full text is in.
  3. If no full-text source is found, mark the paper as abstract-only.

Use multiple sources in parallel when possible. For example, run OpenAlex and arXiv API queries concurrently.

Deduplicate in this order:

  1. DOI
  2. PMID, PMCID, arXiv ID, or SSRN ID
  3. Normalized title plus year

5. Screen and rank

Read screening-rubric.md when ranking or comparing papers.

Keep papers that are:

  • Directly relevant to the question
  • Methodologically meaningful
  • Influential, recent, or both
  • Useful to compare against each other

Separate these categories explicitly:

  • Peer-reviewed papers
  • Preprints and working papers
  • Surveys or review articles
  • Benchmarks, datasets, or position papers

Never imply that arXiv or SSRN papers are peer reviewed unless publication status is verified.

6. Read and extract evidence (CRITICAL — read the entire paper)

This is the most important step. For each shortlisted paper, fetch and read every page of the paper via the scripts/fetch_and_parse helper. Do not hand-roll PDF downloads, do not pass raw PDFs to the Read tool, and do not settle for abstracts when full text is accessible.

Canonical command

SKILL_DIR="$HOME/.claude/skills/research-papers"
"$SKILL_DIR/scripts/fetch_and_parse" "<identifier>"

<identifier> can be a DOI, arXiv ID, PMID, PMCID, or URL — in any common form (10.1038/..., arxiv:2301.08243, https://arxiv.org/abs/2301.08243, PMC4304851, etc.). The script:

  1. Resolves the identifier into canonical IDs.
  2. Runs the OA cascade: arXiv (HTML→PDF) → PMC (XML→HTML) → Unpaywall → OpenAlex best_oa_location → Semantic Scholar openAccessPdf → Crossref TDM links → DOI landing.
  3. Caches the raw file and a layout-aware Markdown parse to ~/.cache/research-papers/<canonical_id>/.
  4. Appends a unique <!-- END-OF-PAPER:<sha> --> sentinel to the parsed file.
  5. For PDF parses, extracts embedded figures to <cache>/images/, drops images that repeat on ≥25% of pages (journal logos, page headers, watermarks), and emits inline ![](path) references in the parsed Markdown for the rest.
  6. Prints a JSON record with status (ok, abstract_only, failed), parsed_path, parsed_lines, parsed_chars, sentinel, read_plan (a chunked list of {path, offset, limit} Read calls covering the whole file), figures (a list of surviving image entries), source, and a tried log.

Mandatory reading protocol (when status is ok)

You MUST:

  1. Execute every entry in read_plan in order. Each entry maps directly to a Read tool call: Read(path, offset=offset, limit=limit). The plan is sized so each chunk fits the harness's 2000-line page; for short papers it has one entry, for long papers it has several. Reading only the first chunk of a multi-chunk paper is the same as not reading the paper.
  2. Confirm the sentinel. The final chunk's last lines contain <!-- END-OF-PAPER:<sha> -->. Compare the <sha> you see with the sentinel field from the script's JSON. If they match, you have read to the end. If you cannot quote the matching sentinel, you have not finished reading — go back and read the remaining chunks before writing any synthesis.
  3. Do not skim. The parsed Markdown contains the abstract, body, figure captions, tables, and references. Methods often hide caveats that contradict the abstract; limitations sections are where authors disclose where their results don't generalize; tables in appendices often hold the headline number behind a claim. Skipping any of these produces a synthesis the user cannot trust.

If parsed_lines is missing from the JSON (older cached parses created before this protocol existed), re-run with --force to regenerate it; do not proceed without a read_plan.

Reading figures

The figures array is your menu of available images. Each entry has:

  • path — absolute path to a PNG you can pass to the Read tool. The Read tool is multimodal: Read(path) on a PNG renders the image inline.
  • size_kb — file size hint.
  • instances — copies in the source PDF; >1 is unusual for content figures and may signal repeated decoration that slipped past the filter.
  • caption_nearby — true when the parsed Markdown has a "Figure N" / "Table N" / "Scheme N" / etc. caption within ~500 chars of the image reference. Advisory only — many real figures (chemical structures, schematic insets, equation renders) lack such captions, so do not use this as a hard filter.

Use judgment, not a rule. Read figures whose content matters to the synthesis question:

  • Always read figures cited by name in a passage you are about to summarize ("as shown in Figure 3, …").
  • Read figures whose captions describe quantitative results, benchmarks, ablations, or schematics central to the method.
  • Skip figures whose captions describe peripheral material if your synthesis won't reference them.
  • When caption_nearby is false and size_kb is small (under ~5KB), it is often an inline equation render or sub-component — read it only if the surrounding text indicates it carries meaning.

Repeating page decoration (logos, journal banners, watermarks) is filtered before this list reaches you. If you spot something that looks like decoration anyway, ignore it; do not waste a Read call.

Always set OPENALEX_EMAIL (and ideally UNPAYWALL_EMAIL) in the environment before invoking the script. Without it Unpaywall is skipped and OpenAlex falls into the slower common pool; with it, full-text recovery rates roughly double for paywalled DOIs. Other useful env vars: SEMANTIC_SCHOLAR_API_KEY, NCBI_API_KEY, NCBI_EMAIL.

Cascade fallback

The script handles cross-source resolution internally — there is no need to manually try OpenAlex after arXiv fails, or to look up PMID→PMCID, or to retry on 429s. If the script returns failed, it has exhausted the cascade. Inspect the tried array in the JSON to see what each step returned.

If you still want to try a specific URL the cascade missed (e.g., an author homepage), pass the URL directly:

"$SKILL_DIR/scripts/fetch_and_parse" "https://example.edu/~author/paper.pdf"

Extraction from full text

From the parsed Markdown, extract:

  • Introduction: Problem framing and motivation
  • Methods: Core method or argument, experimental design
  • Results: Main findings, benchmarks, quantitative outcomes
  • Discussion: Interpretation, comparison with prior work
  • Limitations: Stated limitations and caveats
  • Key figures/tables: Summarize main quantitative results from tables and figure descriptions

Read thoroughly. Do not skim. The user is asking you to research papers because they want deep understanding, not surface-level summaries. The read_plan + sentinel protocol above is non-negotiable; treat any synthesis written without quoting the matching sentinel as incomplete and rewrite it after finishing the read.

When full text is truly unavailable

If the script returns status: "abstract_only" or failed, surface that clearly in the output and explain which steps were tried (from the tried field). Tag every claim with its evidence depth:

  • Full text [Full text]
  • Abstract only [Abstract only — full text unavailable: {reason from tried log}]
  • Metadata only [Metadata only]

7. Synthesize for the user

Read output-shapes.md when the user wants a shortlist, literature review, comparison table, or research brief.

The answer should:

  • Start with the conclusion or recommendation
  • State how the search was scoped
  • Present the selected papers with concise reasons for inclusion
  • Flag preprints, surveys, and evidence gaps
  • Include stable links and enough metadata for retrieval

8. Handle uncertainty

If the evidence base is thin, conflicting, or very recent, say so directly.

If a paper was found through an index but the full text was not accessed, label the synthesis as metadata-based.

Note which papers lacked full-text access and how that limits the synthesis. For example: "3 of 8 shortlisted papers were assessed from abstracts only because full text was paywalled or unavailable, which limits confidence in the methods comparison."

Do not invent:

  • Citation counts
  • DOIs
  • Venues
  • Publication status
  • Full-text findings not actually checked

Minimum Output Standard

Every substantial response should include:

  • The question answered
  • The source coverage used
  • The time window or recency assumptions
  • The selected papers with one-line justification
  • Any important gaps, disagreements, or follow-up search directions

References

  • Source selection and identifier rules: source-guides.md
  • API guidance and source-specific integration rules: api-playbook.md
  • Screening and note-taking rubric: screening-rubric.md
  • Live source behavior and smoke-test outcomes: smoke-tests.md
  • Output formats: output-shapes.md

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.