deep-research-simple

name

deep-research-simple

description

Deep research with structured evidence quality control. Use whenever the user needs exhaustive, multi-source investigation — market analysis, industry research, competitive intelligence, due diligence, investment research, policy evaluation, trend forecasting, market sizing, product comparison, or industry landscape mapping. Trigger on: "深度分析", "帮我调研", "行业研究", "竞品分析", "投资分析", "in-depth analysis", "deep dive", "comprehensive research", "detailed report". Do NOT use for: simple factual lookup, single-source Q&A.

Deep Research Pro

Execute a high-intensity research protocol focused on exhaustive discovery, continuous recursive reflection, and high-density analytical reporting with structured evidence blocks.

Workflow

The execution spine. Each phase points to the standard that governs it.

1. Epistemic Reset — get the current date via bash date and the working directory via bash pwd (all output files go in that working directory — see §Output & Naming). Treat any time constraint implied by the query (e.g. "2026 Q1", "latest", "recent 6 months") as a hard constraint; flag findings outside that window as [OUT-OF-WINDOW]. Do not state facts before search results are reviewed.
2. Query Understanding — see references/query_decomposition.md. Produce an initial decomposition, then run 1–3 broad exploratory searches (titles/snippets only — no full fetch, no evidence blocks; not counted toward the 15-step minimum). Output the revised decomposition explicitly — it is the baseline for scope-fit and dimension-coverage checks.
3. Domain-Skill Loading (before Explore) — check the query against the system prompt's Skill Routing Guide (检索源选型指南), and load every matched professional data Skill via skill_load. Print a loading plan (which Skills, which dimensions each covers). Professional sources first; search_web is fallback only — if the query hits a covered domain, do not run the loop on search_web alone. Multi-domain queries load all matched Skills.
4. Explore — run at least 15 search/data-query rounds following §Search & Evidence. Each round: search → recursive reflection → confidence tagging & contradiction handling. Evidence is written once after all rounds (see §Search & Evidence). Within a loaded Skill's domain, prefer it over search_web; use search_web for narrative/qualitative context and as fallback.
5. Evidence Consolidation — after all rounds, write every evidence block to {topic}_evidence.md in one write_file (deduplicating and calibrating as you write); then batch-verify URLs (install deps if needed: pip install -r scripts/requirements.txt):

   python scripts/verify_urls.py {topic}_evidence.md
   

   Only ❌ FAIL results need action — append [URL-UNVERIFIED] to that block's Confidence field (e.g. Confidence: MEDIUM [URL-UNVERIFIED]); do not delete the block. ✅ PASS and ⚠️ UNCERTAIN are both acceptable (UNCERTAIN means anti-bot block, URL is valid).
6. Outline + Visual Plan — before Write, lay out the report skeleton explicitly in {topic}_outline.md:
   • Section outline: list each section and the key judgment it answers; order by decision-relevance.
   • Evidence mapping: attach the supporting evidence blocks (entries in {topic}_evidence.md) to each section; every key claim must be supported. Archive or drop unused evidence.
   • Visual plan: per section, decide whether a visual artifact is needed and, if so, which type, per the form-selection table in §Visualization & Tables (name the job, pick the form, check the Avoid column); plan tables as a set, consolidating recurring-entity comparisons up front.
   • Gap check: if scope/dimensions lack evidence, or [URL-UNVERIFIED] blocks need replacement sources, run targeted supplementary searches before Write.
7. Produce visuals — execute the outline's visual plan (§Visualization & Tables): for each planned chart/SVG, generate it, save to {topic}_assets/, convert via file_to_url, then run the Pre-embed self-check.
8. Write — generate {topic}_report.md from the outline per §Report Engineering and §Citation & Formatting, embedding each visual with ![caption](public_url) (never a local path — it won't render). Every factual statement carries [(source_name)](specific_url); no OUT-OF-SCOPE evidence for main claims; PARTIAL only with explicit qualification.

Track the plan: before step 1, write these 8 steps as a checklist to {topic}_plan.md via write_file; after each step, rewrite the file via write_file with completed steps marked ✅.

Search & Evidence

Search loop (15+ steps)

This loop runs against the revised decomposition from Query Understanding — the coverage baseline the reflection re-checks each round.

1. Iterative Search: Perform at least 15 search steps to ensure comprehensive coverage. Follow a broad-to-narrow, background-before-detail 3-stage progression — (1) Landscape: macro overview + structural mapping; (2) Deep Dives: targeted investigation per dimension — go vertical on key dimensions: trace data to its methodology, track trends across time periods, and investigate causal mechanisms; (3) Verify & Fill: cross-verification + gap filling. Allocate steps across stages based on topic complexity; earlier stages build the map, later stages stress-test it. Avoid keyword redundancy; ensure each round brings substantial new information.
   • Maximize parallel search: For independent topics/dimensions, launch as many parallel search_web calls as possible, each carrying the maximum allowed queries. Go sequential only when the next query depends on previous results.
   • Search language: Issue search queries in Chinese and English when useful.
2. Selective deep fetch: If the snippet is enough, don't fetch; fetch the full page only when —
   • the snippet is incomplete: a truncated number, a contradiction that needs full-context comparison, a HIGH-confidence candidate that needs confirmation, or a key decision-maker's direct quote (CEO, regulator, industry leader) of unique value; or
   • the snippet may be stale: a fast-changing live metric (GitHub stars/forks, download counts, live rankings, follower counts) — fetch the live page for the current value and record its data date; conclusions the snippet draws from the stale number (e.g. "most popular", "#1") must be re-evaluated too. If a professional Skill covers the domain, use the Skill instead of fetching.
3. Recursive Reflection: After EACH search round, output a Thinking Process and a Summary.
   • Thinking: Reflect on content found, identify unmet needs, and plan the next specific step. Check scope fit and dimension coverage against the revised decomposition. Flag any time-sensitive quantitative indicators (stock prices, market caps, exchange rates, rankings) that need dedicated real-time queries.
   • Summary: Concise recap of key findings.
   • Constraint: Both sections must be short and concise.

Evidence blocks

Use the following 8-field format for every piece of significant evidence:

Claim: [the specific factual claim — plain text, no URLs]
Source: [source name / file name]
URL: [source URL / "File: {filename}, Section: {section}"]
Date: [publication date / "N/A" for files]
Excerpt: [verbatim raw excerpt — no paraphrasing]
Context: [surrounding context that affects interpretation]
Scope fit: [IN-SCOPE / PARTIAL / OUT-OF-SCOPE — fit against the revised decomposition's time scope, geographic scope, target entity, and must-have coverage]
Confidence: [HIGH / MEDIUM / LOW]

One block per claim — do not combine multiple entities or unrelated facts into a single block. Each block should be atomic: one specific claim about one subject.

Scope fit rule: A source can be credible but still not applicable to the user's question. Use IN-SCOPE for evidence that matches the revised decomposition, PARTIAL for evidence that is useful only as context/comparison or has a minor scope mismatch, and OUT-OF-SCOPE for evidence that should not support final report claims.

Source credibility & priority: Prioritize authoritative sources (government sites, academic databases, peer-reviewed journals, official filings, major media); never fabricate data. When multiple sources cover the same fact, cite the more authoritative and more recent — primary/official over secondary reporting, professional/vertical media over general UGC; treat SEO-driven or AI-generated content farms as unreliable. Draw on multiple source types, not just one.

Confidence tagging: Tag every significant finding with one of three levels:

• [HIGH] — Confirmed by ≥2 independent authoritative sources with consistent data.
• [MEDIUM] — Confirmed by 1 authoritative source, or multiple secondary sources.
• [LOW] — Weak sourcing, single unverified claim, or blog-level evidence.

Contradiction handling: Conflicts between sources are signal, not noise. Never suppress them. When conflicting data is found, explicitly document both claims, both sources, and the nature of the conflict (statistical / interpretive / temporal). Temporal conflicts must be flagged as [TEMPORAL-CONFLICT: source A = period X; source B = period Y].

Evidence collection: After all search rounds are complete, write every evidence block to {topic}_evidence.md in a single write_file. Deduplicate, calibrate scope fit, and upgrade/downgrade confidence based on cross-verification in the same pass.

Every major claim in the final report must map back to an evidence block in this file.

Date rules: Record the publication date, not access date. If no date: Date: N/A [accessed YYYY-MM-DD].

Source differentiation:

• [SEARCH-SOURCED] — evidence from external search
• [FILE-SOURCED] — evidence from user-provided files
• [MIXED] — cross-validated across both channels

Report Engineering

Opening Summary

The opening summary is a findings digest, not a topic introduction: it states the report's highest-value findings at maximum density. A reader who reads only the summary should learn what they could not have known without the research.

Predictability test. Every sentence must fail the question "could someone write this without reading the report?" A sentence that passes is filler or a slogan (e.g. 进入深水区 / 核心矛盾 / 重塑格局 / 拐点 / 元年; "paradigm shift", "inflection point") — cut it or replace it with a finding. Each sentence must carry at least one number, named entity, or specific mechanism, and give specific values, not vague hedges.

Build the summary from these role-sentences — each does a distinct job. Write one of each that applies: aim for all of them in landscape/comparison/evaluation/due-diligence/forecast reports; for other types, keep the ones that fit and drop the rest.

• Landscape — state what exists or the baseline: precise counts plus a structural contrast or trend.
• Counter-intuitive — state the single most surprising, least-predictable finding in the report.
• Limitation — name the most important thing that does not work or is not yet known.
• Reality — give what is true on the ground: from your own evidence, cross-checked against external authority rather than borrowed from it.
• Judgment — close with one forward, decision-relevant call.

These role names are internal scaffolding — never print them in the summary as labels, prefixes, or headings (e.g. no paragraph opening with "反直觉发现：" or "格局："); the findings read as continuous prose.

Evidence bar (MANDATORY). The summary is not exempt from citations — every number and named claim takes its inline [(source_name)](url) tag exactly as in the body; an uncited number is a defect, not a stylistic choice. Never build its punch on a fabricated or weakly-sourced figure: the headline counter-intuitive finding should rest on [HIGH]-confidence evidence.

Layout (MANDATORY). Break the summary into 2–4 short paragraphs separated by blank lines — never one block; each paragraph focuses on one cluster of related findings, at most three or four sentences, then start a new one. Bold the key judgment, the critical numbers, and the single most important finding so a skimmer catches them at a glance. The summary is exempt from the body's minimum paragraph-length rule.

Body Structure

• Conclusion-first at every level: extend the opening's discipline to each section and subsection — lead with the key judgment, then develop the evidence beneath it (inverted pyramid). A reader skimming only the lead sentences should still grasp the report's backbone. This changes ordering, not depth.
• Organize by argument, not by source: each paragraph advances one point and pulls in whatever sources support it; never structure prose source-by-source ("Source A reports… Source B says…"). A source is evidence for a judgment, not the subject of a paragraph.
• Order sections by decision-relevance: put what matters most to the user's question first, not what convention or evidence-gathering order suggests.

Data Source Disclosure (MANDATORY when professional Skills used)

When this research used any professional data Skill (openecon-data / fred-data-skill / worldbank-data / frankfurter-data / stock-data-skill / tianyancha-data / tmdb-data-skill / qimai-data-skill / weko-data, etc.), the report must insert a short "Data Sources" disclosure after the Executive Summary and before the body sections, telling the reader which authoritative databases the report's factual backbone rests on, to improve credibility and verifiability.

Writing the disclosure:

• Heading: ## Data Sources (or ## 数据来源, matching the report's language).

• Length: 80–200 words plus one compact table; no lengthy expansion.

• Must include:

  1. The professional data Skills used and their underlying providers (e.g. openecon-data → FRED / World Bank / IMF / OECD ...); list the provider, not the Skill name.
  2. The dimension each provider covers in this report (e.g. "FRED: US monthly macro indicators", "天眼查: the target company's business registration and equity structure").
  3. Whether search_web general search was used as a fallback, with a qualitative note on its share (e.g. "general search only supplements qualitative context and carries no key numbers").

• A table is recommended, e.g.:

  Provider	Skill used	Dimension covered	Role
  FRED	fred-data-skill	US GDP / CPI / unemployment time series	primary source for key numbers
  Frankfurter	frankfurter-data	USD/CNY exchange-rate history	primary source for key numbers
  General web	search_web	policy interpretation, expert opinion	qualitative fallback

• Do not write this as an "acknowledgments" note or in a marketing tone; its purpose is methodological disclosure — keep it objective and restrained.

• If no professional Skill was used (pure search_web), this disclosure may be omitted; but if even one professional Skill was used, it is mandatory.

Style Adaptation

• Report voice: Final report prose should use a neutral, impersonal style by default. Avoid first-person and second-person address unless the user explicitly requests a different voice.
• Tone: No marketing speak, no sloganeering (e.g., "industry-leading", "paradigm shift", "reshaping the future"). Be professional, restrained, and confident.
• Heading tone: Final report headings must use formal report language that identifies the topic, conclusion, analytical dimension, or section purpose. Avoid click-oriented, conversational, promotional, tutorial-style, and platform-native headline formulas.
• Omit generic Introduction/Background sections unless explicitly required.

Depth and Analysis (Mode-Based)

Pick the depth mode by the report's purpose:

• Academic/Survey mode — to map the full picture (technology surveys, policy research, industry landscapes, market sizing/forecasts): prioritize comprehensive fact-based detail — full definitions, formulas, statistical indicators (CI, metrics), and baseline comparisons; avoid speculative interpretation and support every statement with references.
• Practical/Decision mode — to support a decision (product/vendor selection, investment/equity research, competitive analysis, due diligence): incorporate observations, human insight, Pros/Cons, and actionable trade-offs; land each point on its "so what".
• Most research reports blend both — lean by the dominant intent.
• Insight rule: Key paragraphs must answer "so what" and "why" — don't just state facts: explain why they matter and what impact they have, and the causal mechanism or driver behind them, not just the outcome. Avoid hollow summaries; replace vague claims with specific facts and data. When analyzing multiple comparable entities, focus on differentiators rather than repeating shared patterns — state the common pattern once, then highlight what makes each entity unique.
• Confidence in report: LOW confidence claims must be qualified with hedging language (e.g., "preliminary data suggests...", "unverified reports indicate..."). Do not present LOW confidence evidence with the same certainty as HIGH. When credible sources genuinely conflict, present both positions and state which the weight of evidence favors and why — neither silently pick a side nor blur the conflict into vague hedging.
• Actionable conclusions: The report must end with clear conclusions that include: (1) explicit judgments with supporting evidence, (2) concrete recommendations or next steps with priority, (3) applicable scope — state under what conditions the conclusions hold, key uncertainties, and what evidence would change the judgment.

Length and Paragraph Constraints

• Total Volume: Aim for 5,000+ words; scale with topic complexity. Information density matters more than raw length.
• Paragraph Rules:
  • Each paragraph must be at least 100 words (max 1,000 words).
  • Subsection Rule: Every subsection (e.g., ## 3.1) MUST contain more than one paragraph.
• Natural Transitions: Avoid mechanical enumeration patterns (e.g., "First, second, third", "首先、其次、最后"); use natural transitions between ideas.

Visualization & Tables

Default to showing, not telling: wherever a finding has a shape, show it in the form that fits it most faithfully instead of leaving it in prose. Each form carries a different kind of content:

• Charts (IPython/matplotlib) — quantity: trends, rankings, distributions, numeric comparison.
• SVG diagrams — relationship and structure: process, hierarchy, causal chain, quadrant, the links among entities (see references/svg_diagram_guide.md).
• Tables — dense, mostly categorical/textual reference looked up across many entities.
• Prose — narrative, mechanism, and argument.

Don't add a visual artifact for its own sake. Prioritize visualizing the report's thesis-level findings — the judgments, contrasts, and trends — not decorative filler. Route all calculations through programming tools.

Choosing the form

Identify the task first, then pick the form — don't start by reaching for "a chart". Ask: what single claim, pattern, or comparison must this visual make obvious? — match it to an analytical job in the left column, then read the form off the Use column. What decides the form is the nature of the task (the data's shape, what the reader must see), not whichever metric you happen to have.

How to read the form-selection table — each row is one analytical job: the Use column is the form to use; the Avoid column is the form(s) not to use for that job (the cell says why).

Analytical job (what you are showing)	Use	Avoid
A quantity changing over continuous time (e.g., price, sales, market size, user count)	IPython line chart; multi-series for several entities; add a confidence band for forecasts	bar chart for a long series; drawing a time trend as a discrete ranking chart
A chronology of discrete events / milestones (e.g., launches, policies, funding rounds, version nodes)	a dated table by default; an SVG timeline only when the spacing, clustering, or gaps are themselves the finding	bar / line chart; equal-length bars stacked per event (a fake Gantt) — an event sequence is structural, not a trend