deep-research

Deep Research (8-Step Deep Research Method)

Transform the vague topics proposed by users into high-quality, deliverable research reports through a systematic method.

Core Philosophy

Conclusions come from mechanism comparison, not "it feels like"
First nail down the facts, then make deductions
Authoritative sources take priority：L1 > L2 > L3 > L4
Intermediate results must be saved, for traceability and reuse

Reference Documents

Document	Content
`templates/intermediate-outputs.md`	Intermediate Artifact Format Template
`templates/comparison-framework.md`	Comparison Framework Template
`templates/fact-card.md`	Fact Card Template
`templates/report-structure.md`	Report Structure Template

Working Directory Structure

~/Downloads/research/<topic>/
├── 00_问题拆解.md          # Step 0-1 产出
├── 01_资料来源.md          # Step 2 产出
├── 02_事实卡片.md          # Step 3 产出
├── 03_对比框架.md          # Step 4 产出
├── 04_推导过程.md          # Step 6 产出
├── 05.5_校验记录.md        # Step 6.5 产出（独立 Agent 校验）
├── 05_验证记录.md          # Step 7 产出
├── FINAL_调研报告.md       # Step 8 产出
└── raw/                    # 原始资料存档

For intermediate artifact formats, see templates/intermediate-outputs.md

Source Layering

Tier	Source Type	Credibility
L1	Official documentation, papers, specifications, RFCs	✅ High
L2	Official blogs, technical talks, white papers	✅ High
L3	Authoritative media, expert interpretation, tutorials	⚠️ Medium
L4	Community discussions, personal blogs, forums	❓ Low

L4 Community Sources(mandatory for product comparison research): GitHub Issues/Discussions, Reddit, Hacker News

Execution Process (8-Step Method)

After each step is completed, immediately write to the corresponding file.

Step 0: Determine the Question Type

Question Type	Core Task	Focus Dimensions
Concept comparison type	Establish a comparison framework	Mechanism differences, applicable boundaries
Decision support type	Weigh trade-offs	Cost, risk, benefit
Trend analysis type	Sort out the evolution trajectory	History, driving factors, predictions
Problem diagnosis type	Root cause analysis	Symptoms, causes, evidence chain
Knowledge organization type	Systematic organization	Definitions, classifications, relationships

Step 0.5: Timeliness Sensitivity Assessment (BLOCKING)

Sensitivity Level	Typical Domains	Source Time Window
🔴 Extremely high	AI/large models, blockchain	3-6 months
🟠 High	Cloud services, front-end frameworks	6-12 months
🟡 Medium	Programming languages, databases	1-2 years
🟢 Low	Algorithm principles, design patterns	Unlimited

🔴 Mandatory Rules for Extremely High-Sensitivity Domains：

Include time constraints when searching (time_range: "month"）
Official sources take priority (documentation, blogs, Changelog)
Mandatory version number labeling ("latest version supported" is prohibited)
Blogs older than 6 months are for historical reference only
Key information confirmed by at least 2 independent sources
Verify by directly visiting the official download page (do not rely on search caches)
Search for the protocol names supported by the product (MCP, ACP, etc.)

Step 1: Problem decomposition and boundary definition

Break the vague topic into 2-4 researchable sub-questions, andclearly define the research subject boundary(population/region/time/level).

→ Save：00_问题拆解.md

Step 2: Source layering and authority locking

Search strategy(highly sensitive domains):

Targeted search of official sources (restricted to official domains)
Direct verification on the official download page (BLOCKING)
Search for protocol/feature names (BLOCKING)
Time-limited broad search
Version verification
Community voice mining (GitHub Issues, Reddit)

Applicable subject check (BLOCKING): Before including a source, you must verify that the applicable subject matches the research boundary.

→ Save：01_资料来源.md(continuously updated)

Step 3: Fact extraction and evidence cards

Convert sources intoverifiable fact cards, distinguishing between "what the official source says" and "what I infer".

→ Save：02_事实卡片.md(continuously updated)

Step 4: Build a comparison/analysis framework

Choose fixed dimensions based on the question type:

General: goals, mechanism, inputs and outputs, pros and cons, applicable scenarios, cost-benefit
Concept comparison: definition, trigger method, executing entity, determinism, resource management, security boundary
Decision support: implementation cost, maintenance cost, risk, benefit, team capability requirements

→ Save：03_对比框架.md

Step 5: Reference baseline alignment

Ensure that the definitions of all compared parties are stable, generally accepted, and unambiguous.

Step 6: Derivation chain from facts to conclusions

Explicitly write out the derivation process of "fact → comparison → conclusion", so that every conclusion can be traced back to specific facts.

⚠️ Derivation safeguard: Conclusions must not quietly escalate the level of certainty in the fact cards.

If a fact card says "may" → the conclusion must not say "will"
If a fact card says "in theory" → the conclusion must not say "in practice"
If fact card A says "only X is banned" + fact card B says "Y may be affected" → the conclusion must not say "both X and Y are banned"
Self-check: After writing each conclusion, trace back to the cited fact cards and confirm whether the level of certainty is consistent

→ Save：04_推导过程.md

Step 6.5: Independent Agent verification (BLOCKING)

Timing: After the fact cards + derivation process are complete, and before writing the final report.

Principle: Follow the "plan verification" specification in CLAUDE.md — producer ≠ reviewer.

Execution method: Launch an independent Agent (Task tool), and give 02_事实卡片.md and 04_推导过程.md to the Agent to verify the following dimensions:

Data accuracy: Key numbers (prices, version numbers, parameter scale, etc.) should undergo secondary search verification, with at least 3-5 core data points spot-checked
Reasoning logic: Whether the conclusion has jumps, whether the certainty level has been quietly upgraded
Omission check: Whether any key comparison dimensions of interest to the user have been omitted

→ Save：05.5_校验记录.md

Iron rules：

❌ Do not skip this step and directly write the final report
❌ Do not self-verify (an independent Agent must be launched)
✅ Verification passed → continue to Step 7-8; verification found errors → trace back and correct the fact cards/reasoning process

Step 7: Use case validation (Sanity Check)

Use a typical scenario to verify whether the conclusion holds, and check for counterexamples.

→ Save：05_验证记录.md

Step 8: Deliverable processing

Delivery trio：

One-sentence summary: Can be directly repeated at a meeting
Structured sections: Use subheadings to break up the reasoning chain
Traceable evidence: Key facts are accompanied by source links

→ Save：FINAL_调研报告.md

→ Package：tar -czvf ~/outcome.tar.gz -C ~/Downloads/research <topic>

Report output structure

# [调研主题] 调研报告

## 摘要
[一句话核心结论]

## 1. 概念对齐
## 2. 工作机制
## 3. 联系
## 4. 区别
## 5. 用例演示
## 6. 总结与建议
## 参考资料

See templates/report-structure.md

Quality checklist

🎯 Boundary conservation check (BLOCKING - prevent research sprawl)

Core problem: The problem most likely to arise in research is not "not researching enough", but "researching too scattered".

Check process：

Review the core question: What were the sub-questions broken down in Step 1? Write them down in one sentence.
Material relevance audit: For 01_资料来源.md each item of material, use the following structured criteria to judge:
- "Which sub-question can this material answer?" → write down the corresponding sub-question number
- If it cannot correspond to any sub-question → delete it, don't feel bad
- If it is "somewhat related but not direct" → downgrade it to supplementary material, and do not include it in the main report
- ★ High-risk research (involving policy, healthcare, law, etc.): it is recommended to use the Task tool to launch an independent Agent to review relevance judgments (producer ≠ reviewer)
Fact card slimming: For 02_事实卡片.md each card, ask:
- "If this card is deleted, can the core conclusion still hold?"
- If yes → this card iscognitive burden, move it to an appendix or delete it
Report focus check: Every section in the final report must be traceable to a sub-question from Step 1

Typical symptoms：

Symptom	Manifestation	Problem
Boundary sprawl	Researching A, and incidentally looking into B, C, D	The report is bloated and the focus is blurred
Material hoarding	Collect 50 items of material, use only 10	Wastes time and adds noise
Concept divergence	Introduce 3 new concepts when explaining one concept	Reader cognitive overload
Show-off extension	"Actually, there is an even deeper mechanism……"	Deviating from the user's actual needs

Iron rule: The goal of research is toanswer questions, not toshow off breadth of knowledge。

Core checks

All core conclusions are supported by L1/L2-level facts
The comparison dimensions are complete, with no key differences omitted
At least one practical use case validates the conclusion
References are complete and links are accessible
Every citation can be directly verified by the user
The one-sentence summary is clear and repeatable

Timeliness check (🔴🟠 BLOCKING for sensitive domains)

The timeliness of the materials has been annotated
Version numbers are clearly annotated
Official sources have been prioritized
The download page has been directly verified
Protocol/feature names have been searched
GitHub Issues have been mined

Applicable-subject consistency check (BLOCKING)

The research boundary has been clearly defined
Every piece of material is annotated with its applicable subject
There is no subject confusion in the fact cards
There is no subject confusion in the report

Check for distinguishing execution scope from theoretical risk (BLOCKING)

Core issue: When research involves "actions" such as bans, restrictions, or policy enforcement, the most common mistake is to equatetheoretical riskwithactual consequences。

Error pattern：

Fact card A correctly records "only Gemini was disabled" (a confirmed actual consequence)
Fact card B correctly records "OAuth tokens can theoretically access Gmail/Drive" (security rationale/theoretical risk)
The reasoning process equates B's theoretical scope → with A's execution scope
The final report states "the entire account ecosystem is affected" ← this is a substitution

Three-layer distinction (must be clearly annotated in fact cards and reports)：

Layer	Meaning	Annotation format	Example
Confirmed	First-hand user reports confirm it happened	`[已确认]`	"Gemini service was disabled"
Official rationale	The enforcing party's explanation/motivation	`[官方理由]`	"OAuth tokens may be abused to access a broader range of Google services"
Theoretical risk	Technically possible but not confirmed by user reports	`[理论风险]`	"Services such as Gmail and Drive may be implicated"

Checklist：

When bans/restrictions/enforcement actions are involved, do the fact cards distinguish the three layers?
In the reasoning process, is there a logical leap directly from "theoretical risk" to "confirmed consequence"?
In the final report, is the description of the enforcement action strictly based on the "confirmed" layer?
Are "official rationale" and "theoretical risk" presented as analysis/explanation rather than as facts that have occurred?

Iron rule: "X may technically occur" ≠ "X has already occurred." When describing enforcement consequences in a report, only facts at the "confirmed" layer may be used. "Theoretical risk" may be presented as an analytical dimension, but it must be clearly annotated and must not be mixed into factual statements.

Typical incident: The research report says "the entire Google account ecosystem may be affected" (based on the theoretical scope of OAuth), and the article accordingly writes "Gmail, Drive, and Cloud are all implicated—your digital life is cut off." In reality, user reports only show Gemini/Antigravity being disabled, while Gmail/Drive are completely unaffected. Readers who experienced it pointed out the error, and the author's reputation was damaged.

Source thoroughness requirements

URL accessibility: All links are publicly accessible
Precise citation location: Specify the exact section/page number
Content correspondence: The citation can be found in the original text
Timeliness annotation: Annotate the publication/update date
Unverifiable information: Annotate [来源受限], and do not use it as the sole support

Final reply specifications

✅ Should include：

One-sentence core conclusion
Summary of key findings (3-5 points)
Package file location (~/outcome.tar.gz）

❌ Prohibited from including：

List of process files
Detailed research steps
Working directory structure

Version history

Version	Changes
v2.1.0	Added Step 6.5: Independent Agent verification (BLOCKING); facts and reasoning must be verified before writing the report
v2.0.0	Refactoring: Templates moved out to templates/, SKILL.md streamlined
v1.6	Community voice mining mechanism
v1.5	Official download page verification, protocol name search
v1.4	Timeliness sensitivity judgment mechanism
v1.3	Source thoroughness requirements
v1.2	Applicable target verification mechanism
v1.1	Intermediate artifact management
v1.0	Initial version