agentleFS
JinchengGao-InftyJinchengGao-Infty/agent-loadout/skills/lit-review/SKILL.md

lit-review

Skill3 starsChanged 8 months agoMITView on GitHub

Lightweight literature review: search arXiv/Semantic Scholar/OpenAlex/PubMed, screen abstracts, read key papers, and produce a structured Markdown report. Use for quick topic surveys, related work exploration, or catching up on a research area. Chinese triggers: 查论文, 找论文, 论文搜索, 看看有什么论文, 调研一下, related work, 最新进展, 领域综述, 快速调研.

19 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use review-r, validate-bib and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • luischanciSkill

    review-r

    Run the R code review protocol on R scripts. Checks code quality, reproducibility, domain correctness, and professional standards. Produces a report without editing files.

    Also in 4 projects that use this

  • luischanciSkill

    validate-bib

    Validate bibliography entries against citations in all manuscript files. Find missing entries and unused references.

    Also in 4 projects that use this

  • bidodevSkill

    devils-advocate

    Challenges decisions, plans, and code by systematically arguing the opposing side. Surfaces risks, pokes holes in assumptions, and stress-tests thinking before committing. Supports intensity levels (gentle, balanced, ruthless, linus) and works with conversation context or a specific file reference. Trigger on requests like "challenge this", "poke holes", "what could go wrong", "play devil's advocate", "linus mode", or "/devils-advocate".

    Also in 4 projects that use this

  • shanggqmSkill

    data-analysis

    数据分析技能,提供结构化的数据查询、统计分析和报告生成工作流。当用户需要查询数据库、进行数据统计分析、生成分析报告时使用。按规范输出原始数据、计算结果、Markdown报告和HTML可视化报告。

    Also in 4 projects that use this

  • seikaikyoSkill

    interview-me

    需求不明時的意圖萃取訪談:一次一題、每題附上自己的猜測、聽出「真正想要 vs 覺得應該要」,直到能預測使用者反應(約 95% 信心)才動工。適用:需求缺少對象 / 動機 / 成功標準 / 約束,或使用者點名「訪談我」「先確認一下」「我們確定嗎」。明確自足的指示、純資訊查詢、機械性操作不適用。

    Also in 4 projects that use this

  • SentrySkill

    commit

    Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.

    Also in 4 projects that use this

  • +3 more from luischanci

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 14 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 14

    Distinctive

    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:

    Search → Screen → Read → Report, all in-conversation.

    line 9
  2. Distinctive:

    If the user gave a clear topic, proceed directly.

    line 17
  3. Distinctive:

    If the user provides non-English keywords:

    line 31
  4. Distinctive:

    Use expanded terms to build variant queries for broader coverage.

    line 36
  5. Distinctive:

    Use MULTIPLE search strategies in parallel.

    line 42
  6. Distinctive:

    Run 2-3 variant queries using expanded keywords to cover different angles

    line 49
  7. Very specific:

    Free, no API key needed: Use /search/bulk endpoint (NOT /search which requires key).

    line 57
  8. Distinctive:

    When the topic touches medicine, biology, clinical, health, or neuroscience:

    line 73
  9. Distinctive:

    When targeting NeurIPS, ICLR, ICML, EMNLP:

    line 85
  10. Distinctive:

    After collecting results from all sources, merge into a unified list:

    line 101
  11. Distinctive:

    When merging duplicates, keep the richest fields: prefer S2 abstract > OpenAlex abstract, prefer S2 citationCount, keep all source URLs

    line 107
  12. Distinctive:

    Read ALL abstracts yourself.

    line 134
  13. Distinctive:

    Keep all High papers (target: 5-15)

    line 140
  14. Distinctive:

    Keep Medium papers only if total High < 8

    line 141
  15. Very specific:

    Use WebFetch on https://ar5iv.labs.arxiv.org/html/{arxiv_id} (HTML version of arXiv papers, much easier to parse than PDF).

    line 154
  16. Very specific:

    If ar5iv is unavailable, fall back to the abstract page: https://arxiv.org/abs/{arxiv_id}

    line 156
  17. Distinctive:

    Write a structured Markdown report.

    line 177

“Common” is measured: kept by at least 6 in 10 of the 17 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.

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

Lit-Review — Lightweight Literature Survey

You ARE the reviewer. No external pipeline, no PDF downloads, no multi-agent debate. Search → Screen → Read → Report, all in-conversation.

Topic: $ARGUMENTS


Step 0: Clarify Scope & Prepare Keywords (30s)

If the user gave a clear topic, proceed directly. Otherwise ask ONE round of questions:

  • What specific aspect/problem are you investigating?
  • Any time range preference? (default: last 2-3 years)
  • Breadth vs depth? (default: balanced, ~10 key papers)
  • Language preference for the report? (default: match user's language)

Extract from the topic:

  • Keywords: 2-4 core search terms (English, for API queries)
  • Categories: arXiv categories (e.g., cs.LG, cs.CL, stat.ML)
  • Time range: year_min (default: current_year - 2)
  • Focus questions: what specifically the user wants to learn

Keyword Translation & Expansion

If the user provides non-English keywords:

  1. Translate to academic English phrases (2-8 words each). Preserve domain abbreviations (CNN, SVM, RAG, etc.).
  2. Expand each keyword with synonyms, abbreviations, hypernyms/hyponyms. E.g.:
    • "检索增强生成" → retrieval augmented generation → expand: RAG, retrieval-augmented LLM, grounded generation
    • "思维链" → chain of thought → expand: CoT, step-by-step reasoning, reasoning chain
  3. Use expanded terms to build variant queries for broader coverage.

Step 1: Search Papers (1-2min)

Use MULTIPLE search strategies in parallel. Run at least 2-3 sources for any topic.

1a. arXiv API (primary for CS/ML/AI/Physics/Math)

curl -s "http://export.arxiv.org/api/query?search_query=all:{query}&start=0&max_results={N}&sortBy=submittedDate&sortOrder=descending" | head -500
  • Build query: all:keyword1+AND+all:keyword2 (max 2-3 terms per query, AND logic)
  • Run 2-3 variant queries using expanded keywords to cover different angles
  • Fetch 30-80 papers total
  • Parse XML: extract <entry> blocks with title, summary, id, published, authors

1b. Semantic Scholar Bulk API (primary for citation data + broad coverage)

curl -s "https://api.semanticscholar.org/graph/v1/paper/search/bulk?query={query}&limit=100&fields=title,year,citationCount,abstract,venue,externalIds,openAccessPdf&year={year_min}-{year_max}&sort=citationCount:desc"
  • Free, no API key needed. Use /search/bulk endpoint (NOT /search which requires key).
  • Returns: title, abstract, year, venue, citationCount, DOI, ArXiv ID, PDF URL
  • sort=citationCount:desc to get highly-cited papers first
  • Note: tldr field is NOT available on bulk endpoint; use abstract instead
  • Pagination: response includes token for next batch if needed
  • ExternalIds: externalIds.DOI, externalIds.ArXiv for cross-referencing

1c. OpenAlex API (broad coverage, good for non-CS fields)

curl -s "https://api.openalex.org/works?filter=title_and_abstract.search:{query},from_publication_date:{year_min}-01-01&sort=relevance_score:desc&per_page=50&select=id,title,authorships,publication_year,primary_location,abstract_inverted_index,cited_by_count,concepts"
  • Free, no API key needed (polite pool: add mailto=user@example.com for faster rate)
  • Covers journals, conferences, preprints
  • abstract_inverted_index reconstruction: " ".join(w for w,_ in sorted(((w,p) for w,pos in idx.items() for p in pos), key=lambda x:x[1]))

1d. PubMed E-utilities (for biomedical/clinical topics)

When the topic touches medicine, biology, clinical, health, or neuroscience:

# Step 1: Search for IDs
curl -s "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=pubmed&term={query}&retmax=30&retmode=json&sort=relevance"
# Step 2: Fetch details (batch up to 20 IDs comma-separated)
curl -s "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id={id1},{id2},...&retmode=xml"
  • Free, 10 req/s without API key
  • Parse XML: ArticleTitle, Abstract/AbstractText, Journal/Title, ArticleId[@IdType="doi"]
  • Essential for medical/bio topics where arXiv has zero coverage

1e. OpenReview API (for ML venues with review scores)

When targeting NeurIPS, ICLR, ICML, EMNLP:

curl -s "https://api.openreview.net/notes/search?query={query}&limit=50&source=forum"
  • Filter by venue: &venue=ICLR.cc/2025/Conference

Search strategy priority

  1. arXiv + Semantic Scholar — always first, run in parallel
  2. OpenAlex — when arXiv coverage is thin, or for journal papers
  3. PubMed — when topic involves biomedical/clinical
  4. OpenReview — when targeting specific ML venue papers

Step 1.5: Merge, Deduplicate & Enrich

After collecting results from all sources, merge into a unified list:

Deduplication (by priority)

  1. DOI match: Normalize DOIs to lowercase, exact match → merge
  2. ArXiv ID match: Same arxiv_id → merge
  3. Title match: Lowercase + strip punctuation, fuzzy match (>90% similarity) → merge
  4. When merging duplicates, keep the richest fields: prefer S2 abstract > OpenAlex abstract, prefer S2 citationCount, keep all source URLs

Crossref Enrichment (for papers missing DOI)

For papers without DOI (typically from arXiv):

curl -s "https://api.crossref.org/works?query.bibliographic={title}&rows=1&select=DOI,title,author,container-title,abstract"
  • Match by title similarity before accepting the DOI
  • Fills in: DOI, journal name, sometimes abstract
  • Free, polite pool (add mailto header for better rate)

Output

A unified, deduplicated table:

FieldSource priority
titleany (first found)
abstractS2 > PubMed > OpenAlex > arXiv
citationCountS2 > OpenAlex
DOIS2 > Crossref > OpenAlex
arxiv_idarXiv > S2
pdf_urlS2 openAccessPdf > arXiv
venueS2 > OpenAlex > PubMed

Step 2: Screen & Rank (1-2min)

Read ALL abstracts yourself. For each paper, assign:

  • High: Directly addresses the user's focus questions
  • Medium: Related methodology or adjacent problem
  • Low: Tangential or irrelevant

Selection criteria:

  • Keep all High papers (target: 5-15)
  • Keep Medium papers only if total High < 8
  • Drop all Low papers
  • Citation boost: Papers with >100 citations in the same relevance tier get priority

Sort selected papers by relevance (not date).


Step 3: Deep Read Key Papers (3-5min)

For the top 5-10 High papers:

3a. Fetch extended content

Use WebFetch on https://ar5iv.labs.arxiv.org/html/{arxiv_id} (HTML version of arXiv papers, much easier to parse than PDF).

If ar5iv is unavailable, fall back to the abstract page: https://arxiv.org/abs/{arxiv_id}

For non-arXiv papers: use the DOI URL or publisher page via WebFetch.

3b. Extract key information

For each paper, note:

  • Problem: What problem does it solve?
  • Method: Core technical approach (1-3 sentences)
  • Results: Key quantitative results or claims
  • Limitations: Acknowledged or apparent weaknesses
  • Relevance: How it connects to the user's questions

3c. Identify connections

  • Which papers build on each other?
  • What are the competing approaches?
  • Where do results conflict?

Step 4: Generate Report (2-3min)

Write a structured Markdown report.

Report Template

# {Topic} Literature Review

> Generated: {date} | Sources: {sources_used} | Found: {total_found} → Deduped: {after_dedup} → Selected: {selected}

## 1. Overview
<!-- 2-3 paragraphs outlining the field landscape and trends -->

## 2. Method Categories
<!-- Group by approach, not chronology -->

### 2.1 {Method Category A}
- Core idea
- Representative works: [Paper1], [Paper2]
- Strengths and weaknesses

### 2.2 {Method Category B}
...

## 3. Key Paper Reviews

| # | Paper | Year | Citations | Core Contribution | Method |
|---|-------|------|-----------|-------------------|--------|
| 1 | [Title](url) | 2025 | 123 | ... | ... |

### 3.1 {Paper Title}
- **Problem**: ...
- **Method**: ...
- **Results**: ...
- **Limitations**: ...

## 4. Method Comparison

| Method | Strengths | Weaknesses | Best For |
|--------|-----------|------------|----------|
| ... | ... | ... | ... |

## 5. Research Gaps & Future Directions

## References
[1] Author et al. "Title." Venue, Year. DOI: xxx

Report output

  • Save to: ~/Desktop/lit-review-{topic-slug}-{date}.md
  • Also display a concise summary (5-8 sentences) in the conversation

Key Principles

  1. You are the reviewer — don't delegate to external tools. Read, think, synthesize.
  2. Abstracts are enough for screening — only fetch full text for papers you're actually analyzing.
  3. arXiv keyword tips: max 2-3 keywords per query, AND logic, too many = 0 results.
  4. Always use 2+ sources — single-source reviews miss papers. arXiv + S2 is the minimum.
  5. Keyword expansion matters — translate and expand before searching. One extra synonym can surface 20 more relevant papers.
  6. Deduplicate before screening — don't waste time reading the same paper from different sources.
  7. Prefer breadth first — survey 30 papers shallowly, then zoom in on what matters.
  8. Be honest about limitations — flag when a paper needs human attention.

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.