/literature-review

name: literature-review
description: Find, verify, and synthesize scientific literature — from "what's the seminal paper for X" through full multi-source reviews. Covers grounding claims in real retrieved sources, avoiding fabricated citations, handling retractions, and calibrating confidence to evidence strength.
license: Apache-2.0
metadata:
  # Non-biomodel: sends user's query to Crossref (with contact email when
  # configured) and to OpenAlex (with the user's OpenAlex api_key —
  # required since 2026-02-13; no email is ever sent to OpenAlex).
  third_party:
    # The leaf /rest-api-metadata-license-information/ page now 404s though
    # still in search indexes. Parent docs landing carries the license
    # statement ("Almost all of the metadata we hold is reusable without
    # restriction") and is less likely to rot. Docs page, not a ToU —
    # info_url. verified 2026-06-30
    - kind: service
      name: Crossref
      info_url: https://www.crossref.org/documentation/retrieve-metadata/
      privacy_url: https://www.crossref.org/operations-and-sustainability/privacy/
    - kind: service
      name: OpenAlex
      terms_url: https://openalex.org/OpenAlex_termsofservice.pdf
      privacy_url: https://openalex.org/OpenAlex_privacy_policy.pdf

Literature review

A literature question has two halves: finding the papers a domain expert would point to, and turning them into something more useful than a reading list — a synthesis that says what's established, what's contested, what's new, and where the holes are. Both halves can fail quietly and look like competent output until someone checks.

Setup (any agent, no API key)

This is a **pure skill** — `kernel.py` is deterministic Python (plain HTTP/stdlib calls to CrossRef and OpenAlex) and _you_ (the base model) do all the reasoning: the finding, the synthesis, the prose. There is no `host` runtime and no LLM API. Load the helpers once per session in a Python cell:

exec(open("<this skill's directory>/kernel.py").read())

Nothing auto-loads it outside Claude Science. Then call the helpers directly — `verify_dois`, `crossref_lookup`, `search_openalex`, `expand_citations`, `extract_dois`, `style_pass`. If a helper name is not defined, you haven't exec'd `kernel.py`.

Configuration is via environment variables, not a host — no LLM key is involved:

• `OPENALEX_API_KEY` — required for the OpenAlex-backed steps (`search_openalex`, `expand_citations`); free at https://openalex.org/settings/api.
• `HOST_USER_EMAIL` — optional contact email for the CrossRef/doi.org polite pool (falls back to `git config user.email`; never sent to OpenAlex).

Read the request for what it's actually asking

"What's the paper for X" wants one or two specific citations; "what's the evidence on X" wants a synthesis; "compare A and B" wants a comparison, not two adjacent summaries; "where are the gaps" wants the gaps, with the survey as supporting material. A two-word lay query wants you to choose the scope a domain expert would default to and say so up front — "I'll take this as asking about human RCT evidence; the animal literature is separate." Ask a clarifier only when the answer would genuinely change what you do.

Grounding: retrieve first, then write

For broad-survey, where-are-the-gaps, and compare-methods requests, the first move is a literature sweep — `search_openalex` / `crossref_lookup` from `kernel.py`, plus your agent's own web search and any literature/data MCP tools it has connected (PubMed, Semantic Scholar, bioRxiv, ClinicalTrials.gov, …), using whichever fits the field — and the answer is built from what comes back. Your recall picks the framing; the retrieval picks the citations. A real survey usually carries on the order of fifteen or more distinct primary-paper DOIs, because each claim is anchored to the paper that established it; a handful of review citations is a reading list, not a synthesis. When the question is after a _specific_ paper — "the original," "the seminal," a named trial or method — find the highly-cited primary publication that the follow-ups all cite, not a review or news piece about it.

That applies even when you know the answer cold. Resolving the DOI for a paper you're certain of — the Transformer paper, a textbook constant, a landmark trial — is a one-second tool call, and it's the difference between a citation and a claim about a citation. Verification is something that happens in your tool trace, not a sentence in your reply. **A DOI you emit either resolves to a real paper that says what you claim, or it's a fabrication, and the difference is checkable in five seconds.** When you have author/year/journal but not the DOI, look it up via CrossRef or OpenAlex rather than pattern-completing one; when even those details are hazy, that's a search query, not a citation. For recent developments, contested findings, or anything you "remember" from near or after your knowledge cutoff, retrieval isn't optional.

After the first sweep, take the two or three most relevant hits and walk one step in each direction on the citation graph: pull their reference lists (backward) and their cited-by lists (forward), then fold anything new and on-topic into the set before you start writing. The seminal paper a field builds on surfaces in the backward step; the recent work that extends or contests your top hits surfaces in the forward step, and neither reliably appears in a keyword sweep alone. `expand_citations(doi)` in `kernel.py` returns both directions from OpenAlex.

Retractions and the null result

Sensational papers are findable because they were sensational, and some were later retracted or failed to replicate. CrossRef's `updated-by` field links a paper to notices updating it; `update-to` links a notice to the works it updates. `verify_dois` checks both directions and retains title/subtype checks. Its `retracted: true` flags retraction-related metadata, so inspect the relationship direction to d