One task: hand it a concept, and it mines neighboring concepts from real retrieved abstracts, draws this map, and hands the papers back to you to read. A model can draw a concept map from half-baked memory—sometimes right, sometimes wrong; here every node is locked to a real retrieved abstract, and the map is only as wide as what it retrieved, no more and no less.
First read references/sci-cli.md—CLI detection steps, usage, and iron rules.
Then read references/output-system.md—the three-layer output system and HTML shell specification.
The map is intentionally designed to be one layer deep: center + real neighbors. A multi-layer, progressive deep-learning map is a different, heavier task—leave it to SciMaster, not here.
Steps (fixed order)
Step 0 — Confirm the CLI is available
Run sci --version. If not installed, give the install command and stop; if there is an authentication error, prompt sci init and stop. Do not skip.
Step 1 — Anchor the concept and run multidimensional retrieval
First run the main retrieval with the input term as the central concept,sci search that term,--mode low,--limit 20,--prefix tied to the concept.
After the main retrieval, run at least 2 additional supplementary retrievals to verify neighbor nodes, rather than generating the entire map from just the central query. Choose supplementary retrievals from the following angles:
- Method neighbors: the techniques, data types, and detection methods most often connected to the central concept
- Application scenarios: the diseases, populations, tasks, or clinical entry points the central concept enters
- Contrast concepts: alternative methods, competing routes, or baseline methods that repeatedly appear in the abstracts
- Interpretation tasks: downstream tasks such as tissue of origin, mechanism explanation, risk stratification, and predictive indicators
- Frontier combinations: combined terms appearing in recent abstracts, such as multi-omics, fragmentomics, foundation model, etc.
Each supplementary retrieval must be listed in the HTML's "Retrieval Coverage" and "Retrieval Transparency" so the user can see which dimensions were covered this time.
If the term is ambiguous, first confirm which meaning the user wants, then retrieve.
Step 2 — Mine neighbors from the abstracts and write a substantive explanation for each node
Read the retrieved .json, and extract two things from the abstracts for each node:
A. Central concept explanation (3–5 sentences, anchored to sources) Not just a definition—clearly state three things, 1–2 sentences each, with inline source citations:
- What it is (core mechanism or working principle)
- What problem it solves, or in what scenarios it is useful
- What the most core connection is between it and neighboring concepts
B. Neighbor nodes (5–8), each must have a substantive explanation
For each neighbor node, output the following four items, all from real retrieved abstracts:
- Concept name + relationship type(e.g. "method", "subclass", "application scenario", "contrast concept")
- What it is: 2–3 sentences clearly explaining the core content of this concept, so readers unfamiliar with it can build basic understanding
- Connection to the center: 1 sentence clarifying why it is on this map and what its relationship to the central concept is.
- Supporting literature ID(e.g., [E3], [E7])
"What it is" cannot be a one-sentence label — after reading it, the user should be able to describe this concept in their own words, not just know its name. If a neighbor appears in the abstract but there is not enough content for you to write a substantive explanation, do not put it on the map; better to have one fewer node.
Screening criteria: supported jointly by at least 2 abstracts; annotate when supported by a single paper; exclude overly broad words such as study/method/model; label the relationship type on each edge; label the supporting literature ID on each node.
Step 3 — Draw the map, in two forms
Mermaid(output directly in the terminal and in report.md): Concept map, with the central node in the center, neighboring concepts around it, and relationships labeled on the edges (short Chinese, such as "is a subclass of", "provides a method", "contrasted with").
Standalone HTML file(written to {topic-slug}/map.html):
A visual version of the same map. Design requirements: white background, clear labels, moderate density, suitable for screenshots in PPT; hovering over a node shows a one-line description; inline SVG or Canvas, without introducing large frameworks. Generate according to the output-system.md shell specification, with accent color #0891b2(cyan).
Step 4 — Recommended starter reading list Pick 3–6 papers from the real papers supporting the map, with one line for each explaining the reason for inclusion (defines the central concept, is a key paper for some neighbor, latest progress, etc.).
Step 5 — If you can't find it, say you can't find it If the search results cannot support any neighbor node, directly say "failed to find enough neighboring concept support for this concept through search", suggest using more specific search terms, and do not fill in the map from memory.
Output format (terminal)
━━━ [中心概念] ━━━━━━━━━━━━━━━━━━━━━━━━
[是什么,1–2句,[E1] 标注]
[解决什么问题或用在哪,1–2句,[E2] 标注]
[与邻居的核心连接,1句]
邻近概念
─────────────────────────────────────
▸ [邻居 A] [关系标签] [E3][E5]
是什么:[2–3 句,说清核心内容和工作原理]
与中心:[1 句,为什么它在这张地图上]
▸ [邻居 B] [关系标签] [E2]
是什么:[2–3 句]
与中心:[1 句]
…(5–8 个,格式相同)
[Mermaid 代码块]
→ 地图已写入:{topic-slug}/map.html
推荐入门
─────────────────────────────────────
Smith et al. 2023 — "论文标题"
→ 入选理由(一句话)
Deliverables
After the search ends, create a {topic-slug}/ subfolder in the current directory and output four things:
- Terminal — directly print the defined TUI format
report.md— generate according to theoutput-system.mdstructured Markdown specification: stable YAML front matter + at-a-glance conclusion + concept adjacency table + Mermaid concept map + recommended starter readings + learning path + evidence table + search transparency + reusable JSONmap.html— self-contained HTML, accent color#0891b2(cyan)references.bib— merge the.bibfiles generated by all queries, deduplicate, and keep only the literature entries actually cited in the report
HTML signature experience:SVG concept star map + neighbor description cards + recommended reading list, accent color #0891b2(cyan). Below the star map, every neighbor node must have a card (what it is in 2–3 sentences + its connection to the center in 1 sentence), and must not rely only on hover. Implement the hover tooltip with JS mousemove (do not use <title>). For the HTML component specification, see the bear-map section of output-system.md .
For simple queries, give only 1–2 lightweight next steps. When starting a new field, give specific suggestions: which papers to read first, which neighbor to expand along, which nodes have thin evidence and require caution.
Honest boundaries
Every node and every edge on the map must be traceable to a real retrieved abstract. Concepts that cannot be anchored are not put on the map. The map is only as broad as what was retrieved — this is a slice of the real literature, not a complete ontology, and it should be presented as such in the output. A multi-layered progressive learning map is another, heavier capability; guide users to SciMaster rather than faking depth here.
Gotchas
- SVG map nodes must not overlap: When generating node coordinates, they need to be evenly distributed (a regular octagon or similar layout), and adjacent nodes should not be crowded together, especially when node labels are long.
- DOI links must be clickable: In the reading list cards, all paper titles with a DOI must be rendered as
<a>links, and must not be left as plain text because it was forgotten during generation.