From litreview
Academic literature orientation skill that searches papers via free keyless APIs (PubMed E-utilities + OpenAlex) by default — with the Consensus MCP as an optional enhancement lane when connected — builds a strategic search plan using PICO (default) or SPIDER / Decomposition / hybrid as fallbacks, and synthesizes findings into a formatted Word (.docx) research guide. Grill-me intake (research question specificity + framework hint + tentative depth) before the recon search; a second forcing checkpoint after Phase 2 confirms framework + sub-areas + depth before searches consume budget. Configurable depth (5/10/20 queries) controls coverage vs. speed. Output is a 'launching pad' — an orientation guide that lets a researcher dive in confidently, not a finished review. Use when the user starts literature-oriented research (e.g., 'litreview on [topic]', 'literature review on [topic]', 'I'm starting a literature review on X', 'I'm writing a paper on X', 'help me research X', 'I'm doing research on X', 'can you help me research X'). Do NOT use for single one-off paper searches wanting a quick list — that's a plain PubMed/OpenAlex (or Consensus) query.
How this skill is triggered — by the user, by Claude, or both
Slash command
/litreview:litreviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Portability:** Works anywhere with outbound HTTPS — the default search lane is **free keyless APIs** (PubMed E-utilities + OpenAlex, no account, no key, no MCP). The **Consensus MCP is an optional enhancement lane** used only when connected in this session. Node.js with `docx` package is required for document generation, and (in CLI) `bash_tool`. Works in Claude Code CLI natively and in Cla...
Portability: Works anywhere with outbound HTTPS — the default search lane is free keyless APIs (PubMed E-utilities + OpenAlex, no account, no key, no MCP). The Consensus MCP is an optional enhancement lane used only when connected in this session. Node.js with
docxpackage is required for document generation, and (in CLI)bash_tool. Works in Claude Code CLI natively and in Claude.ai with Code Execution.
Produce a launching pad — not a finished literature review, but an orientation document that gives a researcher entering an unfamiliar field everything they need to start reading and searching with confidence. Think: what a generous colleague who knows the field would tell you over coffee.
| Lane | When | How |
|---|---|---|
| Free lane (default) | Always available; no key, no plan, no MCP | PubMed E-utilities + OpenAlex via scripts/free_search.py or direct HTTPS (URL templates below) |
| Consensus lane (optional enhancement) | Only when Consensus MCP tools are available in this session | Run Consensus queries in addition to the free lane for its synthesized answer cards |
Lane check (one runtime check — replaces all tier detection): if the Consensus MCP tools are not available in this session, use the free lane — do not attempt tier detection, do not parse marketing copy, do not ask the user about their Consensus plan. If Consensus IS available, additionally run its searches and merge results (dedupe by DOI/title).
PubMed E-utilities (keyless; etiquette: ≤3 requests/second):
https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=pubmed&term=<urlencoded-query>&retmode=json&retmax=20&sort=relevance
— read esearchresult.idlist (PMIDs) and esearchresult.count.https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=<pmid1,pmid2,...>&retmode=json
— per result[<pmid>] read title, authors[].name, pubdate, fulljournalname, articleids[] (the idtype: "doi" entry).&datetype=pdat&mindate=2021&maxdate=3000 (recent) or &maxdate=2015 (historical).https://pubmed.ncbi.nlm.nih.gov/<PMID>/.OpenAlex (keyless; add &mailto=<email> for the polite pool — faster + more reliable):
https://api.openalex.org/works?search=<urlencoded-query>&per-page=20&mailto=<email>
— per results[] read display_name (title), publication_year, cited_by_count, doi, id (OpenAlex URL), authorships[].author.display_name, primary_location.source.display_name (venue).&filter=from_publication_date:2021-01-01 or &filter=to_publication_date:2015-12-31.&filter=type:review.OpenAlex's cited_by_count is the citation-count source for the cross-search intelligence layer (PubMed esummary returns no counts).
Inherited from the research-pack convention; locked verbatim per PR #657's cross-skill consistency audit.
[Not from search — model knowledge] and excluded from cited count. Sparse results stated explicitly, never silently filled.scripts/citation_tracker.py for deterministic counts.mailto. Consensus (if connected): 1 query/sec, sequential execution mandatory. Default discipline: sequential, 1 query/sec across all lanes.See references/search_budget_allocation.md for the sequential-execution rationale + budget ceilings.
| Failure | Behavior |
|---|---|
| Rate-limit / HTTP error on any lane | Wait 3s, retry once, log outcome |
| Search returns 0 results | Note explicitly; "either niche terminology or genuine gap"; never silently fill |
| Network unavailable (free lane exits 2) | Stop, alert user — the free lane needs outbound HTTPS; nothing to detect or upgrade |
| 3 consecutive failures | Stop searching, alert user, share what's collected, ask how to proceed |
| Sub-area returns thin results (<5 papers) | Flag in audit; suggest manual Google Scholar / Scopus supplementation |
| User wants to adjust sub-areas | Update table, re-confirm before searching |
| DOCX validation fails | Unpack XML, fix, repack |
Each question carries explicit "why I'm asking". Stop condition: max 3 before Phase 1.
State the research question in 1–2 sentences. Specific is better — "How do LLMs perform on clinical reasoning tasks compared to physicians?" beats "AI in medicine". Vague questions produce vague reviews.
Why I'm asking: The reconnaissance search hinges on precise terminology. Vague questions produce thin recon results that don't yield a useful framework breakdown.
Refuse mush. Re-ask once with examples if user is too broad. If still vague, deliver with explicit "broad-scope orientation, not depth review" caveat.
Framework — pick one or say "you pick":
- PICO (Population / Intervention / Comparison / Outcome — most clinical questions)
- SPIDER (Sample / Phenomenon / Design / Evaluation / Research-type — social/qualitative)
- Decomposition (Problem / Solution / Evaluation / Limitations — technology-focused)
- Hybrid (you pick which components from which framework)
- You pick — analyze Q1 and recommend
Why I'm asking: PICO is the default for ~70% of clinical questions but maps poorly to qualitative work or technology evaluation. Picking upfront saves the recon search from suggesting a misaligned framework.
Forcing choice with default ("you pick"). The skill surfaces its own framework recommendation after the recon search so user can override. Use scripts/framework_recommender.py for the heuristic.
See references/framework_selection.md for PICO / SPIDER / Decomposition canon.
Tentative depth — pick one. Final confirmation comes after the framework breakdown:
- Quick scan (5 searches)
- Standard review (10 searches)
- Deep dive (20 searches)
Why I'm asking: I ask this twice — once now to calibrate the recon search emphasis, once after the framework breakdown to confirm. Tentative answer affects which sub-areas to surface first; final answer drives search budget allocation.
Forcing choice. Re-asked at the post-Phase-2 checkpoint after the user has seen the framework breakdown.
Stop condition: 3 questions max before Phase 1. The post-Phase-2 checkpoint is its own grill-me moment (framework table + sub-area-adjustment + depth-reconfirmation).
One broad recon search to map themes, terminology, methodological distinctions.
python scripts/free_search.py --query "<broad version of Q1>" --source both --max 20 (or the esearch/works URL templates above)citation_tracker.py --action record_search --session NAME --query "..."citation_tracker.py --action record_papers_received --session NAME --count NSynthesize for the checkpoint:
Choose framework (from Q2 OR override based on recon):
Generate 4-5 sub-area questions mapped to framework components. Each becomes a targeted Phase 3 search.
After Phase 2, halt and present:
| Framework Component | How It Maps to This Topic | Proposed Sub-area to Explore |
|---|---|---|
| (Component 1) | ... | Sub-area 1 |
| (Component 2) | ... | Sub-area 2 |
| (Component 3) | ... | Sub-area 3 |
| (Component 4) | ... | Sub-area 4 |
| Cross-cutting theme | ... | Sub-area 5 |
Surface the practical constraint: search lane in use (free / free+Consensus) + approximate ceiling at ~20 results per query per source.
A wrong framework or sub-area set wastes the search budget. This is the last cheap moment to correct course.
Wait for user response before Phase 3. Refuse to start Phase 3 without explicit user choice.
Sequential (1 query/sec), budget per depth tier. Every search runs on the free lane (free_search.py or the URL templates); if Consensus is available, additionally run the same query there and merge. See references/search_budget_allocation.md for full canon.
"systematic review [topic]" / "meta-analysis [topic]" (OpenAlex: add &filter=type:review)&maxdate=2015 / OpenAlex to_publication_date:2015-12-31) + recent (PubMed &mindate=2021 / OpenAlex from_publication_date:2021-01-01)Throughout: 1 q/sec rate limit. Sequential. Confirm response before next call. Record each via citation_tracker.py.
Three trackers across ALL search results — run scripts/cross_search_aggregator.py --session NAME after Phase 3 completes:
cited_by_count for seminal-work identification.These feed the "Start Here" + "Key Research Groups" + "Bibliography" DOCX sections.
Generate via Node.js + docx library. 8 sections (see references/docx_8_sections.md for full spec):
Document the key docx library patterns:
LevelFormat.BULLET (never unicode bullets)ExternalHyperlink with style: "Hyperlink", full URL (never truncated)columnWidths + cell width), ShadingType.CLEARpython3 -c "import zipfile,sys; zipfile.ZipFile(sys.argv[1]).testzip()" output.docx — no output = intact — then confirm the required sections are present)Reference the docx skill for setup patterns and best practices.
research_guide_<topic-slug>_<YYYY-MM-DD>.docx
Plus:
| Script | Role |
|---|---|
scripts/free_search.py | Free keyless search lane — PubMed E-utilities + OpenAlex via stdlib urllib (--query, `--source pubmed |
scripts/citation_tracker.py | JSON-backed three-count audit at ~/.litreview_sessions/<session>.json |
scripts/framework_recommender.py | Heuristic PICO/SPIDER/Decomposition suggestion from research question |
scripts/cross_search_aggregator.py | Repeat-hits + recurring-authors + citation-per-year ranking after Phase 3 |
references/framework_selection.md — PICO / SPIDER / Decomposition canon (7+ sources)references/search_budget_allocation.md — depth tiers + cross-search intelligence + sequential execution rationale (7+ sources)references/docx_8_sections.md — research guide DOCX spec + technical requirements (7+ sources)Version: 1.1.0
Source spec: megaprompts/09-litreview-megaprompt.md
Build pattern: Path B (direct conversion). Sibling of pulse (research-pack shape). v1.1.0: free keyless APIs (PubMed + OpenAlex) became the default search lane; Consensus demoted to optional enhancement; plan-tier detection deleted per the 2026-06 newgen audit + ClawHub rule #3 (no paid-service dependencies).
npx claudepluginhub motivatedc-creator/saafy --plugin litreviewBuilds a throwaway prototype to answer a design question about UI appearance or state/logic behavior. Guides you through two branches: interactive terminal app for logic validation, or multiple UI variations for visual exploration.