bear-support

bear-support · find supporting literature

One task: you submit a claim, and it brings back genuinely existing supporting literature. The support comes from retrieval, not from memory.

First read references/sci-cli.md—CLI detection steps, usage, and iron rules. Then read references/output-system.md—the three-layer output system (TUI / Markdown / HTML) and the HTML shell specification.

Description

references.bib Generated by default, including all cited literature in this report. Automatically triggered in paragraph mode, no flag needed.

Steps (fixed order)

Step 0 — Confirm the CLI is available Run sci --version. If not installed, provide the installation command and stop; if there is an authentication error, prompt sci init and stop. Do not skip.

Step 1 — Extract claims, identify paragraph mode Extract the core assertion from a single sentence. If the input is a paragraph containing multiple independent claims, automatically enter paragraph mode and split each claim apart to process one by one.

When automatically entering paragraph mode, tell the user: "Detected N independent claims, retrieving each separately." Then start directly without waiting for confirmation.

Assign each claim a stable number:C1、C2、C3. Subsequent queries, evidence tables, and unsupported claims must all refer back to these numbers to avoid confusion in paragraph mode.

Step 2 — Retrieve, and display the query terms For each claim, execute sci search, using --mode low，--limit 10–20，--prefix tied to the claim.Regardless of whether the claim is vague, display the actual query terms used in the output—only when users see "what it searched" can they judge whether the results are trustworthy, and it also makes it easier for them to adjust on their own later.

If the meaning of the claim is genuinely ambiguous (for example, a proper noun has multiple completely different meanings), first confirm with one sentence before executing.

Step 3 — Read the results, filter support candidates Read .json, and filter out candidate literature that truly supports the claim: title, authors, year, and a one-line statement of "how this piece of literature specifically supports this view" (not a paraphrase of the abstract, but the support relationship).

When filtering, use four levels of criteria:

1. Direct support: the research object, variables, direction, and conclusion are all close to the claim
2. Partial support: only supports the mechanism, population, conditions, or a certain sub-claim
3. Indirectly relevant: can only serve as background, insufficient to support the core assertion
4. Exclude: similar in topic but cannot support it, does not enter the evidence table

Only write the first three categories into the evidence ledger; excluded items are only written into retrieval transparency when necessary.

Step 4 — Sort by strength of support Within each claim: direct evidence ranks first, and relevant or partially supporting evidence ranks later. Honestly label the latter as "indirect support" or "partially relevant." Mark the strongest one—it is the one users should cite first.

If there is no direct support but there is partial support, the first-screen conclusion must clearly state "only partial support," and must not package partial support as strong support.

Step 5 — If there is none, say there is none If the search results contain no literature that truly supports the claim, directly say "no supporting literature found" and flag the claim. Do not force weakly related literature in just to fill space.

Output Format

One block per paper, with direct support first and indirect support after:

Smith et al. 2023 — "论文标题"
支撑强度 ████████░░ 强
→ 这篇如何具体支持你的主张（一句话）
查询词：sleep memory consolidation

Strength key: strong = ████████░░, medium = █████░░░░░, weak/indirect = ███░░░░░░░ For indirect support, add after the strength （间接）。

Claims with no supporting literature found:[!] [主张] — 未检索到支持文献, on a separate line, not mixed into the list.

Last line:Preferred citation: Smith et al. 2023 — one-sentence reason

Outputs

After the search ends, create under the current directory {topic-slug}/ subfolder, and output four things:

1. Terminal — directly print the already defined TUI format
2. report.md — according to output-system.md generate the structured Markdown specification: stable YAML front matter + at-a-glance conclusion + evidence ladder + research action recommendations + evidence table + detailed evidence + search transparency + reusable JSON
3. report.html — self-contained HTML, generated according to the output-system.md specification
4. references.bib — merge all query generated .bib files, deduplicate, and keep only the literature entries actually cited in the report

HTML signature experience:Evidence ladder, accent color #16a34a(green). Display the literature area in tabs by "Direct Support / Partial Support / Indirectly Related". For HTML component specifications, see output-system.md in the bear-support section.

For simple queries, provide only 1–2 lightweight next steps. For research writing scenarios, give specific recommendations: where to place the preferred citation, which claims need to be toned down, and what to search for in the next round.

Gotchas

• Do not package partial support as direct support: for literature that only supports the mechanism, a subpopulation, or the background, faithfully note the limitations in both the preferred citation and the first-screen judgment; do not omit them.
• In paragraph mode, claim numbering must run through the entire text: once C1/C2/C3 numbers are assigned, the subsequent evidence table, unsupported claims, and next-step recommendations must all refer back to these numbers; do not change the referencing method midway through the output.
• Empty results must not be deleted: if no supporting literature can be found for a claim, that is a signal and must be retained in the report; do not omit it because it "looks more complete".