← All skills
litreview
Use when the user starts literature-oriented research — 'litreview on X', 'literature review on X', 'help me research X for a paper' — and wants an orientation guide, not a finished review.
About this skill
Use when the user starts literature-oriented research — 'litreview on X', 'literature review on X', 'help me research X for a paper' — and wants an orientation guide, not a finished review.
SKILL.md
litreview.SKILL.mdPlace it in your Syntic skills folder. For Syntic Code, install in your local skills directory, review the contents and run it in a controlled environment first.
---
name: litreview
description: Use when the user starts literature-oriented research — 'litreview on X', 'literature review on X', 'help me research X for a paper' — and wants an orientation guide, not a finished review.
category: Research
version: 1.0.0
tools: []
---
# Litreview — Academic Literature Orientation
Produce a **launching pad** — not a finished literature review, but an orientation report that gives a researcher entering an unfamiliar field everything needed to start reading and searching with confidence. Think: what a generous colleague who knows the field would tell you over coffee. Deliver it as a formatted chat report.
## Search Approach
Use `web_search` / `knowledge_base_search` as the default search lane, targeting academic sources — PubMed, OpenAlex, Google Scholar, and general web search all work; prefer sources that expose citation counts and publication years so recency and impact can be weighted. If a specialized academic search tool (e.g., a Consensus-style connector) is available in the session, use it *in addition to* general search and merge results by deduplicating on title/DOI — don't attempt to detect or reason about which paid tier it's on, just use what's available.
## Integrity Rules
- Cite only papers actually returned by search this session. Anything from background knowledge is labeled `[Not from search — model knowledge]` and excluded from the cited count.
- Track three numbers: searches run / unique papers found (deduplicated by title/DOI) / papers actually cited. Every cited paper needs a retrievable URL (PubMed, DOI, or source link).
- Search sequentially, not in a burst — confirm each result before the next query.
- On failure, retry once with reworded terms; after repeated failures, stop, tell the user what's missing, and share what was collected.
- If a search returns zero results, say so explicitly — "either niche terminology or a genuine gap" — never silently fill with model knowledge.
## Phase 0: Intake (3 questions, one at a time)
1. **Research question**, in 1-2 sentences, as specific as possible — "How do LLMs perform on clinical reasoning tasks compared to physicians?" beats "AI in medicine." Refuse mush; re-ask once with examples if the question is too broad. If still vague after one push-back, proceed but flag the output as a "broad-scope orientation, not a depth review."
2. **Framework hint** — PICO (Population/Intervention/Comparison/Outcome, the default for roughly 70% of clinical questions), SPIDER (Sample/Phenomenon/Design/Evaluation/Research-type, for social or qualitative work), Decomposition (Problem/Solution/Evaluation/Limitations, for technology-focused questions), a hybrid of these, or "you pick" — analyze the question and recommend one after the recon search.
3. **Tentative depth** — quick scan (~5 searches), standard review (~10 searches), or deep dive (~20 searches). This gets reconfirmed after the framework breakdown once the researcher has seen the sub-areas.
Stop at 3 questions before starting the recon search; the post-recon checkpoint below is its own forcing moment.
## Phase 1: Reconnaissance
Run one broad search on a wide version of the research question to map themes, terminology variants, and methodological distinctions (e.g., "LLM" vs "large language model" vs "GPT-style model"; clinical trials vs benchmark evaluation vs case study). Note any coverage gaps — sub-questions the recon results didn't touch.
## Phase 2: Framework Selection + Sub-Areas
Pick the framework (from intake, or override based on what recon surfaced) and generate 4-5 sub-area questions mapped to its components. Each sub-area becomes one targeted search in Phase 3.
## Checkpoint (mandatory pause before spending the search budget)
Present, then wait for the user's response before continuing:
- A 3-4 sentence recon summary: themes, terminology landscape, evidence landscape.
- A framework breakdown table (component → how it maps to this topic → proposed sub-area).
- Depth re-confirmation, with the practical ceiling stated plainly (roughly 20 results per query): quick scan ≈100 results total, standard ≈200, deep dive ≈400.
- Explicit options: proceed as-is / add a sub-area / swap a sub-area / restart with a different framework.
This is the last cheap moment to correct course — a wrong framework or sub-area set wastes the whole search budget. Refuse to start Phase 3 without an explicit user response.
## Phase 3: Targeted Searches
Run sequentially, budget scaled to the confirmed depth:
- **Quick scan (5):** one search per sub-area.
- **Standard (10):** 5 sub-area searches + 2 review-article searches ("systematic review [topic]" / "meta-analysis [topic]") on the top 2 sub-areas + 2 era-gated searches (older vs. newer) on the most important sub-area + 1 follow-up chasing the highest-cited paper's own key terms.
- **Deep dive (20):** 5 sub-area + 5 review-article (one per sub-area) + 4 era-gated (top 2 sub-areas, old and new each) + 3 follow-ups on the top 3 highest-cited papers + 3 spare for chasing surprising threads.
## Cross-Search Intelligence
After Phase 3, look across *all* results for three signals:
1. **Repeat-hit papers** — the same paper surfacing in 3+ sub-area searches is likely foundational.
2. **Recurring authors** — the same author appearing across multiple searches signals a dominant research group; the top 3-5 most frequent matter most.
3. **Citation velocity** — weigh citations against age; a 2023 paper with 150 citations is a much stronger signal than a 2008 paper with 150 citations.
These feed the "Start Here" and "Key Research Groups" sections below.
## Report Structure (8 sections)
1. **Topic Overview** — one tight paragraph (4-6 sentences).
2. **Start Here — Priority Reading Order** — 5-7 papers ordered: best recent review → foundational work → 2-3 frontier papers → a gap/controversy paper. Each gets a link, authors/year, a one-sentence contribution, and a one-sentence "what to look for."
3. **How the Field Got Here** — a short chronological narrative plus a milestone timeline table (year / milestone / significance) and a note on how terminology evolved.
4. **Sub-Area Guides** (one per sub-area): what the research shows (2-3 sentence synthesis with citations), 3-5 key papers with citation counts, 6-10 search terms/synonyms/historical terms, and 2-3 ready-to-paste boolean search strings.
5. **Key Research Groups** — top 3-5 authors/groups with affiliation, sub-area coverage, and a representative paper link.
6. **Open Questions & Gaps** — grouped into methodological, population/context, and conceptual/theoretical gaps, each with a sentence on why it matters.
7. **Bibliography** — alphabetical by first author, every entry linked (PubMed/DOI/source), every inline citation matching an entry.
8. **Audit Log** — search summary (query, filters, results returned, status), the three counts, and coverage notes.
## Error Handling
| Situation | Response |
|---|---|
| Zero results on a search | State explicitly; don't backfill with model knowledge. |
| Sub-area returns thin results (<5 papers) | Flag it; suggest the user may need to check specialized databases directly. |
| Repeated failures across searches | Stop, tell the user what's missing, share what was collected. |
| User wants to adjust sub-areas mid-run | Update the table, re-confirm before continuing to search. |
Install
Syntic App
- 1Create a dedicated folder for this skill in your local skills library.
- 2Place SKILL.md into that folder.
- 3Restart Syntic and invoke this skill on matching tasks.
Syntic Code (CLI)
- 1Save SKILL.md in your local Syntic Code skills directory.
- 2Keep related files in the same skill folder.
- 3Run in a safe environment and validate outputs.