Literature Radar

---
name: literature-radar
description: Scheduled or on-demand sweep for NEW papers in a project's research scope — web-search the recent window, deduplicate against the project's corpus, pre-screen each keeper into a triage-ready digest, and stop for approval. Also does seed-based discovery — from a few anchor papers the user already trusts, trace the related and foundational work outward. Also watches the papers already in the corpus for changes — corrections, retractions, versions of record — and proposes matrix state updates. Use when the user asks "what's new" in their field ("run my radar", "check for new papers", "anything new since last time"), gives you seed papers and wants related/foundational work traced from them ("find papers related to these", "citation search from this paper", "build a starting corpus"), wants a recurring literature watch set up, or a scheduled radar day arrives. Discovery + pre-screen ONLY — inclusion decisions belong to the human and flow through the literature-review skill.
---

# literature-radar — a standing watch on the field

You run a **literature radar**: a periodic sweep that surfaces *new* work in the project's scope and delivers it **pre-screened** — deduplicated, quality-flagged, drafted into triage-ready blocks — so the scholar opens a near-finished digest, not a raw search dump. **Prime directive: discovery and pre-screening only.** You never write to the review matrix or the synthesis; every keeper waits for approval, then enters through the **`literature-review`** skill's triage flow (Mode 1), whose rules govern tiers, KEY, and the quality checklist.

## Step 0 — load the project's rules
Read `review-conventions.md` (the same file the literature-review skill uses): the **Scope** section defines what's in/out; the **`## Radar`** section (template: `../../starter-kit/review-conventions-template.md`) defines cadence, search window, venue list, preprint servers, the digest file's path, and any standing attention-criteria. Also load the current **dedup state**: the matrix's Authors + Cite-key columns, the project's PDF folder filenames, prior digest sections, and — when Zotero MCP tools are present — the live library. If no Radar section exists, offer to set one up (a two-minute interview).

## The sweep
1. **Search the window** (default ~since the last digest, or ~3 weeks): the conventions' topic phrasings × venue list × preprint servers, via web search. **Precision over recall** — "no clearly new in-scope papers this run" is a perfectly good result, and web search is not exhaustive (say so: the radar complements, never replaces, periodic database sweeps like Scopus/WoS).
2. **Dedup ruthlessly** against matrix + folder + prior digests + live Zotero. Watch preprint↔published pairs (match authors + title, not strings). A prior digest's "requested follow-up" items count as in-window even if older.
3. **Per keeper — pre-screen, behind the reading-quality gate:** fetch **open-access PDFs only** (never paywalled; a free-but-bot-blocked PDF = one click for the user — say which). Read what you fetched and declare the **Read basis** (full / partial / abstract-only). Then draft the full triage block per the literature-review skill's Mode 1: every matrix column, tier + KEY + cite-with-care via the project's checklist, and a one-line **corpus-benchmark** (corroborates / extends / contradicts / supersedes which existing row or contested finding).
4. **File the digest**: append a dated section (newest on top) to the project's radar inbox file, with a **"Needs your attention" shortlist** at the top (borderline scope, weak/uncertain quality, possible duplicate or supersession, partial reads, contested-finding impact). Summarise the shortlist + one line per keeper in your reply. Open every dated section with a one-line **run stamp** — model ID · CLARK version (release tag or commit) · scripts run · surfaces reached (index · publisher page · held PDF) — the same "what ran" line the citation report opens with; a digest without it cannot be reproduced or compared across runs (the documentation methods work now asks of AI-built instruments: Crosthwaite & Özer, 2026).
5. **STOP.** Approvals are per-paper and human; on a yes, integration runs through literature-review Mode 1 Step 8 (backup, write, verify), then a Mode 2 regeneration syncs the vault.

## Mode S — seed-based discovery (build or expand a corpus from anchor papers)
Two situations, one motion — **finding the field from what you already trust**: a project starting near-zero, *or* a user who already holds a few key papers and wants the related work around them. The maintenance sweep above watches for what's *new*; this traces *outward from seeds*. On "help me build a starting corpus" **or "I have these papers — find the related/seminal work"**:
1. Take the user's **anchor papers** (2–3+ they already trust) — or, for a truly cold start, find the field's recent *syntheses* first (reviews and meta-analyses are pre-aggregated reading lists).
2. **Claude runs the citation-snowball for you** from the anchors, via the open citation-graph APIs — OpenAlex (free, no key) and Semantic Scholar's Graph API — walking **references (backward) and citations (forward)** one or two hops, ranked by citation count within scope; deliver the ranked hits as the seeding digest. **Then always remind the user** they can cross-check visually if they prefer — the popular explorers ride the *same* open graphs, so they double-check coverage rather than add an independent source: **ResearchRabbit · Litmaps** (its *Monitor* auto-alerts new papers — the manual analogue to this radar) **· Connected Papers** (a co-citation *similarity* map, not a citation tree). State plainly that neither the snowball nor those tools is an exhaustive search: for reproducible recall, systematic database searching (Scopus/WoS) still leads.
3. Deliver as a **seeding digest** (same triage-ready format), explicitly marked provisional: tiers on a young corpus are guesses that firm up as the matrix grows. For a cold-start project, then switch to normal radar cadence; when expanding an existing corpus, fold the keepers in through normal triage.

## Mode C — corpus state watch (what changed about papers you already hold)
The sweep finds what's *new*; this mode checks what has *changed* about the corpus since triage — papers get corrected, retracted, superseded by a version of record, or re-dated from online-first to print, and a matrix row extracted at triage time does not know. Run it on every scheduled sweep, and on demand ("check my corpus for changes"):
0. **Precondition — the corpus is the matrix.** Run this mode only when the conventions' `## Radar` section names the corpus bibliography. The corpus is the set of rows in the matrix (its `Cite key` column), resolved against that bibliography — never the whole file: a shared whole-library export holds other projects' papers (never report them here), and a collection snapshot goes stale (never trust it alone). Write a temporary copy of the bibliography holding only the matrix's keys, run the scripts on that, and delete it. If `## Radar` names nothing, write one line in the digest — *"Corpus state watch not configured: no corpus bibliography in `## Radar`"* — and skip the mode; never choose a bibliography by guesswork.
1. **Records (tool, exhaustive over the corpus):** `python3 ../../starter-kit/check_retractions.py <corpus library.bib> --mailto=<user's email>` (retractions, expressions of concern, Crossref-deposited corrections) and `python3 ../../starter-kit/vor_check.py <corpus library.bib> --mailto=<user's email>` (preprints that now have a published version). Same scripts the citation-integrity skill runs at submission — here they run on the *corpus*, on a schedule, so a change is seen when it happens rather than at the last minute. **A clean script result is index-checked, never clean.**
   **1b. Held-PDF notice scan (tool):** `python3 ../../starter-kit/notice_scan.py <corpus PDF folder>` — page 1 and the last page of every held PDF for *Correction (Month YYYY) · Corrigendum · Erratum · Expression of Concern · Retracted*; quote each hit with the file's creation date, and report a hit only for files that map to a matrix Cite key (filename or title) — other PDFs in the folder go under *held but not in the matrix*; if `## Radar` names no PDF folder, the coverage line says *PDFs scanned: 0 — no folder named*. It proves only the state of the copy you hold: a file downloaded before a re-issue reads clean — pair a clean result with the record's dates, and re-download before trusting a clean on a copy older than the print issue.
2. **Publisher-page glance (judgement layer; ★ KEY rows, plus any row the user names):** Crossref does not carry every correction — some exist only on the publisher's article page, and not always as a visible banner: a notice may sit inside a collapsed panel (author information · notes · versions) that a glance at the rendered page never shows. The glance list is the rows carrying `★` in Key points / Flags — the dashboard's ★ KEY register is the authoritative list (a row marked any other way is not on it until the marker is fixed); report *glanced n of N* so a shortfall is visible. For each KEY row, fetch the page and search its **full text, not only what is visible on load**, for *Correction · Corrigendum · Erratum · Expression of Concern · Retracted*; quote what you find, with the date; list the pages you could not reach. **A page you could not open is unverified, not clean**: it goes under *"Glance these yourself"* with its link, and no `last_verified` is proposed for it. Say plainly that this layer is not exhaustive.
3. **Digest section "Corpus changes"** — in the same dated radar section, placed *above* "Needs your attention" whenever non-empty. Per changed paper: what changed (notice quoted or linked) · which matrix fields may be affected (a Methods correction → re-check extracted N, raters, design; a version of record → update the record and **pin the citekey before editing the year**; a retraction → 🚫 name every synthesis claim that leans on the row) · proposed `record_state` (normal · corrected · retracted · VoR-updated) and `last_verified` (today, with the surface in parentheses per the conventions template, e.g. `2026-09-07 (page + PDF)`) values for the row. **Propose only** — the user applies the change in Zotero and approves the matrix edit through literature-review Mode 1. Write the section on **every** run, even when nothing changed, with a coverage line the reader can audit — *keys checked · PDFs scanned · pages glanced · unreachable* — and propose `last_verified` only for rows read on a notice-bearing surface (the page in full, or page 1 of the held PDF), never from an index-only pass.
4. **Memory:** a change reported once is recorded in the digest and not re-reported unless the state changes again; the conventions' `## Radar` section names the corpus bibliography and the KEY-row glance list.

## Scheduling
The cadence lives in the conventions (e.g. 1st and 15th). Pair this skill with the platform's scheduler (a scheduled task/cron that invokes "run the literature radar for ⟨project⟩") for hands-free runs; any manual "run my radar" works between schedules. Each digest section is dated — the next run reads the previous ones as its dedup floor.

## Boundaries
Never write to the matrix or synthesis · OA-only fetching · declare search-coverage limits honestly (engine, region, recency) · a candidate the user rejects goes into the digest's record (so it never resurfaces as "new") — rejection is information.

## Lessons burned in (provenance)
Field-neutralized from the maintainer's own twice-monthly radar (which pre-screens into a triage-ready `RADAR_INBOX.md`): the pre-filled-digest principle ("the user opens a near-finished triage, not raw candidates"), the attention-shortlist-first layout, OA-only discipline, dedup against *three* surfaces (matrix, folder, prior digests), and the precision-over-recall stance that makes "nothing new" a trustworthy answer.