Skip to content
Back to skills

Literature Review

ASecurity

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.

  • 9 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 14, 2026
researchgobashgitbackend

Works with

  • claude code
  • mcp

Security analysis

A100/100

Scanned October 14, 2026

npx -y skills add Yichen-ZJU/lemvo --skill literature-review --agent claude-code

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.

Security grade badge for Literature Review
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/yichen-zju-literature-review-lemvo/badge)](https://www.skillsdirectory.com/skills/yichen-zju-literature-review-lemvo)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.