One task: before you commit, see who is sitting closest to you. The group that scoops you often uses words you wouldn't use — here we search from angles you wouldn't think of.
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.
Flags
- Default: full-angle scan
-r: only look at the past year or two and preprints (where collision risk is highest)
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.
Step 1 — Compress the idea Distill the idea into one sentence and confirm it. A vague idea returns noise, not signal.
Step 2 — Decompose into 5–6 orthogonal angles Describe the same piece of work from different standpoints:
- Literal phrasing (the user's own wording)
- Method-centered (technique / tool, stripping away the application scenario)
- Problem-centered (the problem to be solved, stripping away the method)
- Conclusion-centered (the specific result expected to be claimed)
- How an adjacent field would phrase it (what another discipline would call this)
- The scooper's title (if someone published faster than you, what would that paper be called)
In the output, explicitly list these 5–6 angles, each with a one-line explanation and the actual query terms used. The user needs to see which directions you searched in order to judge whether coverage is complete enough, and can also add missing angles themselves. After listing them, start retrieval directly without waiting for user confirmation (unless the idea itself is too vague).
Step 3 — Search by angle
Use ultra_lowfor broad angles (free), and rerun the two or three that yielded results with low . When adding -r , bias toward recent results. Use an independent --prefix。
Step 4 — Merge and deduplicate Deduplicate by DOI or title.
Step 5 — Sort into four layers by proximity
- Direct collision: problem + method + conclusion all overlap
- Method twin: your method, someone else's problem
- Problem twin: your problem, someone else's method
- Neighbor: related but not overlapping
For each paper, add a line saying "why it is in this layer". Name the most dangerous one separately at the very top.
Before layering, give each candidate a four-axis score, each axis from 0 to 2 points:
- Problem overlap: whether it solves the same problem
- Method overlap: whether it uses the same technical route
- Conclusion overlap: whether it would claim the same or highly similar findings
- Scenario overlap: whether the population, data, materials, task, or application scenario is close
Layering rules:
- Direct collision: total score 7 to 8, and none of the three axes—problem, method, conclusion—is below 1
- Method twin: method score 2, problem or scenario clearly different
- Problem twin: problem score 2, method clearly different
- Neighbor: total score 1 to 3, or only shares the background domain
If the scoring conflicts with intuition, follow the scoring tiers, and explain the conflict in "why it is in this tier."
Output format
After the search angle list, directly give the collision map (★ is your idea, expanding outward from dangerous to safe):
── 撞车地图 ──────────────── [你的 idea] ──
[!] 直接撞车
Smith 2023 — "论文标题"
邻近度 ████████░░
方法孪生
Jones 2022 — "论文标题"
邻近度 ██████░░░░
问题孪生
Wang 2021 — "论文标题"
邻近度 ████░░░░░░
邻居
Li 2020 — "论文标题"
邻近度 ██░░░░░░░░
──────────────────────────────────────────
Tiers with no literature:— [层名] 此层未检索到, do not disappear from the map.
End with two sentences: where it is crowded, where it is quiet.
Deliverables
After the search ends, create the {topic-slug}/ subfolder and output four things:
- Terminal — directly print TUI format (collision map ASCII)
report.md— according tooutput-system.mdstructured Markdown specification: stable YAML front matter + at-a-glance conclusion + collision tiers + topic selection action suggestions + evidence table + detailed evidence + search transparency + reusable JSONreport.html— self-contained HTML, generated according to theoutput-system.mdspecificationreferences.bib— merge the.bibfiles generated by all queries, deduplicate, and keep only the literature entries actually cited in the report
HTML signature experience:SVG collision radar + four-tier literature tabs, accent color #2563eb(blue). Implement the radar hover tooltip with JS mousemove (do not use <title>). For HTML component specifications, see the bear-scoop section of output-system.md .
For simple queries, give only 1–2 lightweight next steps. When proposing a thesis or worrying about being scooped, give concrete suggestions: whether to continue, which point to avoid, how to revise the title.
Honest boundaries
Not finding a direct collision does not mean you are new. It could be a preprint just released, an article behind a paywall, an unindexed journal, or simply no one has submitted yet. Report what was found and what it shows—do not say "you are safe." A complete novelty argument is a product-level task; hand it to SciMaster.
Gotchas
- Radar chart points must not be empty: when using CSS div concentric circles, points cannot be placed on the rings; SVG must be used. Empty rings have no informational value to users.
- Do not be overly strict with the four-axis scoring: the four axes—problem/method/conclusion/scenario—are each scored 0-2, for a total of 8. In reality, papers scoring 7 and 8 carry the same collision risk for users; do not downgrade a paper from "direct collision" to "method twin" just because one axis is 1 point short, as this underestimates the real risk.
- Do not put review articles into direct collision: reviews and original research have different competitive natures. Reviews almost never pose a threat of "your topic being scooped" and should be placed in the "neighbor" tier.
- Do not report "safe" just because no direct collision was found: database coverage is limited, and this conclusion has no basis.