Multi-Source Research Skill

First evaluate the research scale, then execute according to the unified multi-round framework: Scouting, Defining Metrics, Deep Diving, Converging, Reporting. The scale does not determine whether to adopt multi-rounds, but only decides the breadth, parallelism and round budget of each round. First run any input through SIFT: Stop (pause before using), Investigate the source (check who said it), Find better coverage (look for more credible coverage), Trace claims (track down the original source), then determine the scale level.

1. Evaluate Topic Scale

When the topic is unclear, only ask one clarification question: research object, scope or success criteria. When the topic is clear, score directly:

Dimension	Qualifying Conditions
Sub-topics	Involves 2+ independent questions or objects
Sources	Requires 2+ types of sources, such as official documents, papers, source code, news, communities
Analysis	Requires comparison, ranking, trend, causality or solution judgment
Timeliness	Conclusion depends on date, version, policy or recent changes
Risk	Wrong conclusions will affect important decisions, money, law, medical care or safety

Score	Level	Round Budget & Parallelism
0-1	Small	Scouting round is the main round: 1-2 highly credible sources, converge immediately if evidence is sufficient
2-3	Medium	Scouting + Defining Metrics + up to 2 Deep Diving rounds; parallel self-search with multiple types of MCP search tools
4-5	Large	Scouting + Defining Metrics + up to 3 Deep Diving rounds; assign parallel sub-agents according to gaps

When the user specifies a scope or disables sources, follow the user's restrictions. When the user specifies a round upper limit, follow the user's upper limit.

2. Multi-Round Research Cycle (Default Framework)

All levels share the same framework: Scouting, Defining Metrics, Deep Diving, Converging, Reporting. The level only determines the breadth, parallelism and round upper limit of each round (see [Scale Level Table]).

Start broad then narrow (for medium/large topics or multi-round research): broad queries first, metrics, sub-topics and focus points emerge from broad results, narrow deep diving at the end; skipping broad queries and directly deep diving into single points is a violation. Small topics converge according to [Scale Level] and are not subject to this restriction.

Order: Scouting (broad) → Defining Metrics (dimensions/sub-topics emerge from broad results) → Deep Diving (narrow, only target gaps) → Converging.

Scouting (broad) : Use 1-2 types of search tools to conduct a round of broad queries, and produce a topic terrain briefing: key entities, core controversies, available source types, candidate sub-questions. For small topics, if evidence is sufficient in this round, converge directly without forcing subsequent rounds.
Defining Metrics (from broad outputs) : The main agent reads the scouting briefing and defines the evaluation dimensions or sub-question list for this research. For large topics, split using [MECE Dimension Table]; for small/medium topics, list 2-5 key questions to be verified. Metrics come from clues found in scouting, not fixed templates. When comparing multiple objects, dimensions must be answerable by all research objects.
Deep Diving (narrow) : Each round only targets the gaps left from the previous round. Query terms or sub-tasks must be explicitly driven by the findings of the previous round: new entities, new conflicts, uncovered dimensions. Do not repeat covered queries. For large topics, assign parallel sub-agents by dimension (see [Large Research Path] for delegation contract); small/medium topics are searched by the main agent. Deep Diving dual triggers: gap-driven + user-specified dimensions; when specified, upgrade effort to directly read underlying implementations (source code/state machine/protocol original text).
Gap inventory at the end of each round : List three columns: covered (with evidence markers), still gaps, new clues, and decide where to target in the next round or stop accordingly.
Convergence and stop criteria : Stop when any of the following signals are met, and state the stop basis in the report:
- a) Full coverage: All key dimensions have evidence, or explicitly marked
```
[unknown]
```
  with explanations of what was searched;
- b) No new information: No new key facts or independent sources in this round, the expected benefit of continuing search is approximately zero;
- c) Reached upper limit: Used up the round budget in [Scale Level Table]. The upper limit is a safety budget, not indicating information saturation; when stopping due to reaching the upper limit, must mark uncovered dimensions as
```
[unknown]
```
  .
Report : Write according to [Output Format], record the actual rounds and stop signal in the first line.

3. Large Research Path

Only use when the score is 4-5, or the user explicitly requests in-depth research/multi-agent parallelism.

MECE Split : Select a primary dimension, add a secondary dimension if necessary.

Dimension	Applicable Scenarios
Object	Comparison of A/B/C solutions, products, frameworks, companies
Perspective	Technical, commercial, user, compliance, security perspectives, etc.
Time	History, current status, recent changes, trends
Source Domain	Official/source code, academic, first-hand data, community/media

After generating candidate sub-questions, merge overlapping items, fill in missing items, and finally retain 3-6 sub-tasks with clear boundaries. Each sub-task must be independently completable and together cover the user's question.

Delegation Rules : Independent sub-tasks are delegated to sub-agents in parallel; if no sub-agent tools are available in the current environment, execute manually in sub-task order and mark "not parallel" in the results. The main agent does not repeat full-scale searches, only performs summary, deduplication, conflict handling and final judgment.

When comparing multiple objects and evidence can be obtained independently for each object with unified comparison dimensions, split by object, assign one sub-agent per object, deliver compressed briefings and prohibit dumping original text; otherwise, use MECE dimension split. When the user clarifies the scope, re-send the assigned sub-tasks immediately, do not use the old scope. When sub-agents submit in batches, mark "correction/supplement" one by one - correction means overturning old conclusions, supplement means adding new evidence; update the report only by marking, not rewriting the full text.

Each sub-agent prompt must include:

Sub-task boundaries, excluded scope, success criteria
Recommended source types or tool types
Output format: 2-3 sentences of summary, key evidence, complete and accurate URL, credibility marker; only deliver URLs that support key conclusions, do not list all auxiliary hits
The
```
tool / complete query / number of hits / conclusion
```
of the counter query (see [Search and Evidence]) must be written into the delivery, cannot only write "searched"
"For coding-related tasks, please load the
```
karpathy-guidelines
```
skill first and provide a karpathy evidence summary at the end of the final reply."

4. Search and Evidence

First inventory currently available search MCP tools: web search, content crawling, official documents, code search, repository documents, structured data, etc.
Without expanding the user's scope, use multiple relevant MCP search tools as much as possible; the default target is 3 types, at least 2 types. Mark
```
single-source restriction
```
when only 1 type is available.
Prioritize highly credible sources: official documents, source code, release notes, standards, papers, first-hand data.
Communities, blogs, tutorials can supplement explanations, but cannot independently support key conclusions.
Independent requests are preferably parallel; each result must first extract the main judgment, then organize hierarchically according to "judgment / limitation / evidence". The final output must leave clear white space and be written into scannable short blocks; prohibit stuffing conclusions, limitations, evidence, sources, conflicts into the same paragraph or the same dense bullet point.
Record source tools, titles, complete and accurate URLs, release dates or versions. The complete and accurate URL must point to the specific page supporting the claim, source code permalink, paper DOI/landing page, release note, standard page or first-hand announcement; do not use search result pages, site homepages, short links, aggregation pages as substitutes.
Must retain complete and accurate URLs for key important information. Key important information includes: conclusion in key sections, basis for credibility markers, ranking/recommendation/risk judgment, conflicting sources, counter evidence, facts that will affect user actions or technical decisions.
Auxiliary sources only used for background understanding do not need to be fully listed in the final output; if not fully listed, explain "auxiliary sources have been searched but not listed one by one". Do not pile search hit results as bibliography to users.
Counter Query : Any key conclusion that will be marked
```
[verified]
```
must run at least one reverse query targeting the specific negative proposition or counter claim of the conclusion (e.g., original conclusion "X is faster than Y" → counter query "benchmark where Y is faster than X" "X performance degradation cases", not general "X criticism"). The actual counter query string and number of hits must be written into the evidence chain or a separate paragraph for review by the main agent and user. Not finding counter evidence can only be recorded as "no opposing evidence found" (may be due to insufficient query terms/language domain/tool coverage), cannot independently increase confidence; if substantial opposing opinions are found, downgrade the original conclusion to
```
[conflicting]
```
or
```
[likely]
```
.

If search returns empty, explain the tried MCP tools, keywords and source types, and give next-step suggestions.

5. Cross-Validation

Marker	Conditions
`[verified]`	Key conclusions: Supported by 3+ independent sources, and at least 1 highly credible. General facts: Supported by 2+ independent sources, and at least 1 highly credible. If the conclusion depends on timeliness (subject is current status, version, policy, price, etc.), the source release date must also fall within the timeliness window corresponding to the topic (e.g., "current API behavior" requires sources within the past 12 months), otherwise can only be marked `[likely]`
`[likely]`	Supported by 2+ sources but does not meet the `[verified]` threshold (e.g., lacks highly credible sources, or only 2 sources for key conclusions)
`[single-source]`	Supported by only 1 source
`[conflicting]`	Substantial contradictions exist between sources
`[unknown]`	Insufficient evidence found

Key conclusions marked

[verified]

must also provide complete and accurate URL evidence; if unable to provide complete and accurate URL, even with multi-source summaries, can only be marked

[likely]

or lower.

Evidence Form Axis, orthogonal to the above markers: First-hand direct reading (source code/actual measurement/original text) / Document statement (official document/specification) / Inference (derived from analysis). Fixed writing: Confidence level only uses the 5 canonical square bracket markers in [Cross-Validation]; the form is written separately as

Evidence form: first-hand direct reading/document statement/inference

, not placed in square brackets or creating combined markers.

Independence Judgment : Reprint of the same press release, mirror of the same project document, repeated publication by the same author are not considered independent sources. Distinguish first-hand from secondary citation : 3 media citing the same original report count as 1 independent source; only tracking down different first-hand sources counts as multi-source. When unable to track down the first-hand source or determine whether it is homologous, count as 1 independent source, and note

[source independence not verified]

after the marker. When contradictions cannot be resolved, list the claims and evidence of all parties, do not write speculation as fact.

6. Output Format

Key URL Citation Rules

Key important information can only retain short tag citations in the main text, e.g.,
```
[S1]
```
; complete and accurate URLs must appear in the adjacent source entries. Do Stuff the judgment section into dense long paragraphs just to insert URLs on the spot.
Each key conclusion defaults to citing 1-3 strongest sources; multi-source verification uses the most authoritative, independent, and closest to the original source as representatives, do not list all auxiliary sources.
If one URL supports multiple key conclusions, list it once in the source section and cite it with a short tag in the main text, e.g.,
```
[S1]
```
, but the entry corresponding to
```
[S1]
```
must include the complete and accurate URL.
If unable to obtain a complete and accurate URL, cannot mark
```
[verified]
```
; downgrade to
```
[likely]
```
,
```
[single-source]
```
or
```
[unknown]
```
, and explain the gap.
Only list all source URLs when the user explicitly requests a complete bibliography, audit list or research log; otherwise keep the minimum set of key sources.

Tone: Explain to people clearly, not fill out a form

The report form is determined by the topic and research findings, do not use fixed chapters. Answer briefly if the research is shallow, expand on conflicts if there are many conflicts, draw diagrams if the process is complex. Traceable evidence is the bottom line, not a format requirement.

Bottom Line (Violation if any is missing)

Key conclusions retain evidence markers: only use the 5 canonical markers in [Cross-Validation] (
```
[verified]
```
/
```
[likely]
```
/
```
[single-source]
```
/
```
[conflicting]
```
/
```
[unknown]
```
).
```
[source independence not verified]
```
is an additional note, not the 6th marker. Do not create variants; write
```
[conflicting]
```
for conflict resolution and explain the result in the main text.
Key conclusions can provide complete and accurate URLs; if unable to provide, downgrade the marker and explain the gap.
Conflicts, uncertainties, and evidence gaps must be written out, do not smooth them out for fluency.

Last line:

Rounds: <actual number of rounds>, Stop: <a/b/c + one sentence reason>

; add

Split method: <primary dimension> × <secondary dimension>, total <n> sub-tasks

for large-scale research.

List verification boundaries at the end of the report: which are first-hand direct reading, which are document statements, which are inferences/not actually measured.
Mark explicitly "unverified, not a fact" for counterintuitive or bypass inferences without actual measurement.
When the user explicitly feedbacks that the report is hard to read, first give the main judgment summary with metaphors + behavioral language; positioning information such as paths, line numbers, URLs are retained in independent evidence sub-items, not replaced or deleted.

Legend Block (Must be placed at the beginning)

List the markers actually used in this report at the beginning of the report, with a plain language explanation for each. The same applies to terms: each technical term in the main text must either be in the legend or have a plain language explanation at its first appearance.

For Unfamiliar Readers

Users usually have limited understanding of the topic. Prioritize explaining functions and impacts, do not assume readers understand implementation details. Self-check: Can you grasp the main judgment and reasons without checking materials?

White Space and Rhythm

Separate conclusions, limitations, and evidence, only talk about one thing per paragraph, do not mix long sentences.
Alternate long and short sentences, focus on short sentences. Read like research notes, not a flow chart.
Use mermaid diagrams when appropriate (processes, role relationships, timelines), only draw key structures in diagrams, do not include all details.
Put the main judgment first, followed by limitations and exceptions, do not hide them in the middle of paragraphs.

Counterexamples (Prohibited)

Information blocks: One paragraph simultaneously contains conclusions, limitations, evidence, sources, conflicts.
Bureaucratic jargon: Empty connecting phrases such as "It must be pointed out", "It is worth noting", "In summary".
Self-created marker variants (e.g.,
```
[conflicting→resolved]
```
).
Throwing out terms without explanation.

Source Section Rules:

The source section only lists key sources by default. Key sources refer to sources that directly support conclusions in key sections, credibility markers, conflict judgments, counter evidence, ranking/recommendation/risk judgments. Ordinary background, repeated reprints, weakly relevant tutorials, search hit pages do not enter the source section, unless the user requests a complete source list.
Each source entry must include a complete and accurate URL;
```
URL/Source
```
cannot only write domain names, homepages, search pages, short links or non-directly locatable descriptions such as "official documents".
For sources that support key conclusions or are repeatedly cited, note
```
[Credibility high/medium/low, bias explanation]
```
in a single line (e.g., "[Credibility high, vendor self-statement, has interest relationship]"). The bias explanation must specify the specific bias direction or interest relationship, uninformative annotations such as "may have bias" "neutral stance" are not accepted. Not required for ordinary auxiliary sources.
For volatile content supporting
```
[verified]
```
key conclusions (news pages, policy pages, commercial statements, personal blogs, etc.), prefer to submit
```
https://web.archive.org/save/<URL>
```
for archiving and link the archived URL in the citation; mark "not archived" and the reason if archiving is not possible. Stable official documents, paper DOIs, source code commit/permalink do not require mandatory archiving.

Boundary Cases

Save path: Write to

docs/research/YYYY-MM-DD-<topic>.md

when the user requests saving, otherwise only output in the conversation. In cases such as insufficient tools, sub-agent failure, overlapping results, downgrade according to the general principles of this skill (mark restrictions, retain available results, retain the most authoritative sources after deduplication).

When to Switch Out of This Skill

This skill handles multi-source research and cross-validation. Switch to a more appropriate tool or sub-agent first when the following signals appear, do not force it in this skill:

Signal	More Appropriate Handling Method
Need to check repository code implementation, call relationships, local file structure	Hand over to code retrieval tools or code exploration sub-agents (grep / read / ast types)
Need to check npm/pip/cargo package API, official documents, external library behavior	Hand over to document/web retrieval tools or document retrieval sub-agents
Involves architecture judgment, multi-system trade-offs, technical selection decisions	Hand over to consultant-type/secondary review-type sub-agents, or the main agent clearly states reasoning boundaries
Need to perform calculations, data processing, command verification	Hand over to shell/script execution tools
The user wants coding/modifying code instead of research	Exit research mode, hand over to the implementation stage

multi-source-inquiry

NPX Install

Tags

SKILL.md Content (Chinese)