Run a literature review using paper search and primary-source synthesis. Use when the user asks for a lit review, paper survey, state of the art, publication-corpus review of a lab/PI/author, or academic landscape summary on a research topic.
Installs into .claude/skills of the current project.
Are you the author of Literature Review?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/yichen-zju-literature-review-lemvo)
---
name: literature-review
description: Run a literature review using paper search and primary-source synthesis. Use when the user asks for a lit review, paper survey, state of the art, publication-corpus review of a lab/PI/author, or academic landscape summary on a research topic.
argument-hint: <topic-or-lab-or-author>
---
# Literature Review
Investigate the user's topic, lab, PI, or author as a literature review.
Derive a short slug from the topic (lowercase, hyphens, no filler words, ≤5 words). Use this slug for all files in this run.
## Tools (Claude Code)
- Web search: `WebSearch`. Fetch pages: `WebFetch`.
- 证据分级与全文核验义务见 `../shared-references/full-text-verification-policy.md`(承重声明必须 full-text 级;arxiv MCP 的 `[pdf]` 为可选依赖,失败降级 alphaxiv,再降级只产出 fragment 级证据)。
- Academic papers, backend priority with auto-degradation (record the probe result in provenance): (1) `alphaxiv` MCP tools (`discover_papers`, `get_paper_content`, `answer_pdf_queries`, `read_files_from_github_repository`) when visible and healthy — on 401/403 immediately stop retrying and drop to (2); (2) **arxiv MCP (primary, keyless)** — `mcp__arxiv__search_papers` / `download_paper` / `read_paper` / `search_paper_text` for systematic search and full-text claim verification; (3) fallback: WebSearch/WebFetch on arxiv.org, degradation explicitly noted in provenance.
- Subagents: the `Agent` tool with `subagent_type` `researcher` / `verifier` / `reviewer`. Spawn parallel researchers in one message. Real output goes to files.
## Workflow
1. **Plan** — Outline the scope: key questions, source types to search (papers, web, repos), time period, expected sections, and a small task ledger plus verification log. When the input appears to name a lab, PI, author, institution lab page, or author profile, run the review as a publication-corpus review: find the lab/author identity first, collect the reachable publication list, then map the research trajectory across that corpus. Write the plan to `outputs/.plans/<slug>.md`. Briefly summarize the plan to the user and continue immediately. Do not ask for confirmation or wait for a proceed response unless the user explicitly requested plan review.
- When updating the plan ledger later, keep edits small. If an edit would require embedding a large markdown block, rewrite the full corrected plan file with Write instead, then continue to final artifact/provenance verification.
2. **Gather** — Use `researcher` subagents when the sweep is wide enough to benefit from delegated paper triage before synthesis. For narrow topics, search directly. Researcher outputs go to `<slug>-research-*.md`. For publication-corpus reviews, the lead agent owns identity resolution and writes `notes/<slug>-publications.md` with reachable titles, years, venues, URLs/DOIs, and gaps before delegating trajectory synthesis. Prefer lab publication pages, author profiles, arXiv/OpenReview/Semantic Scholar pages, and paper search results that expose stable source URLs. Do not silently skip assigned questions; mark them `done`, `blocked`, or `superseded`.
3. **Synthesize** — Separate consensus, disagreements, and open questions. For publication-corpus reviews, also identify 3-5 research trajectories and the 3-5 papers that most changed the corpus direction; rank them by contrastive originality, methodology strength, and relationship to prior art rather than by author prestige alone. When useful, propose concrete next experiments or follow-up reading. For topic/state-of-the-art reviews (not corpus reviews), include a **Reusable Assets** section: directly adoptable baselines (code + reported metrics + reproduction notes), transferable recipes (what to port, what to change, expected mechanism), usable assets (datasets/protocols/checkpoints), A+B combination candidates with complementarity rationale, and a **recipe & necessity comparison** against the closest successful method — input/privileged channels, teacher-student setup, training scale & key hyperparameters with actually-reported resources (never present a big-compute recipe as small-card ready), evaluation endpoints & independent units, which conditions have ablation/derivation support as necessary vs. mere implementation choices, locally reusable parts & remaining gaps, whether limits we additionally impose have scientific/engineering/authorization basis, and the next runnable direct comparison. The literature is construction material, not a veto list; "someone did this before" triggers a delta statement, never a rejection; a limit absent from the literature is a reconsideration clue, not proof it is unnecessary (see research-orchestrator/references/constraint-governance.md). When a concrete bottleneck is identified and a mechanism-level next step is needed, hand off via `../shared-references/grounded-ideation.md` (on-demand, not a required artifact). Generate charts only when real source-backed quantitative data supports them (e.g. matplotlib via Bash); otherwise include a chart specification or comparison table. Use Mermaid diagrams for taxonomies, method pipelines, or lab trajectory maps when the structure is source-supported and changes the reader's research decision. Keep the output to research evidence, source coverage, and next research decisions.
4. **Cite** — Spawn the `verifier` agent to add inline citations and verify every source URL in the draft.
5. **Verify** — Spawn the `reviewer` agent to check the cited draft for unsupported claims, logical gaps, zombie sections, and single-source critical findings. Fix FATAL issues before delivering. Note MAJOR issues in Open Questions. If FATAL issues were found, run one more verification pass after the fixes.
6. **Deliver** — Save the final literature review to `outputs/<slug>.md`. Write a provenance record alongside it as `outputs/<slug>.provenance.md` listing: date, sources consulted vs. accepted vs. rejected, verification status, and intermediate research files used; for publication-corpus reviews, include the publication-log path and unresolved corpus gaps. Before you stop, verify on disk that both files exist; do not stop at an intermediate cited draft alone.