deep-research

name	deep-research
license	MIT
description	Deep, multi-source, fact-checked research on a topic — fan out searches, read primary sources, adversarially verify each claim, and synthesize a cited report. Use when the user wants a thorough research report rather than a quick answer, e.g. "深度调研", "research this properly", "写一份调研报告", "帮我系统调研", "多来源核实", "give me a researched writeup", "背景调查一下". BEFORE starting, if the question is underspecified (scope, region, time window, use-case unclear), ask 2-3 clarifying questions to narrow it. For a single quick lookup use web_search directly; for a whole codebase/feature use the relevant dev skills.

Skill: deep-research

A harness for research you can trust: breadth first (many angles), then depth (primary sources), then an adversarial pass that tries to break each claim before it goes in the report. Built on octo's native tools — web_search, web_fetch, sub_agent, and (for login-gated / JS-rendered / anti-bot sites) the browser tool via the web-access skill. No external services.

The goal is a cited report where every non-obvious claim traces to a source you actually read — not a plausible-sounding summary of search snippets.

0. Scope before you search

Research is only as good as the question. Before any tool call, confirm you can state the deliverable: what question, what decision it informs, what time window, what region/market, what depth. If any of these is missing and would change the answer, ask 2-3 sharp clarifying questions first — don't guess a scope and burn a fan-out on the wrong one.

Then write down, in one line, what "done" looks like. That line is the acceptance criterion the final report is checked against.

1. Fan out — breadth

Decompose the question into 4-8 independent sub-questions, each attacking a different angle (definition, current state, competing views, data/numbers, history, criticisms, primary actors). Independence matters: overlapping sub-questions waste the fan-out.

Dispatch them in parallel. web_search / web_fetch are stateless, so this is exactly the case sub-agents are for:

• One sub_agent per sub-question. Prompt it goal-first, not step-first: describe what to find out, not "search for X" — an anti-bot source may need browser on the main site, and "search" would anchor the sub-agent to web_search.
• Tell each sub-agent to load the web-access skill and follow it, to return findings with source URLs, and to flag anything it couldn't verify.
• Do NOT parallelize browser work — the browser session is single-page and process-shared; concurrent sub-agents fight over one page. Keep browser interaction to a single sequence; parallelize only the stateless search/fetch.

If sub_agent is unavailable in this session, run the sub-questions sequentially inline and say so.

2. Go to the source — depth

Search engines and aggregators are a discovery entry point, not proof. N outlets quoting the same wrong number is circular, not corroboration. For every claim that matters, reach the primary source and read it:

Claim type	Primary source
Policy / regulation	Issuing body's official site
Company announcement	The company's own newsroom / filing
Academic / scientific	The original paper or the institution
Product capability / API	Official docs or source, not blog posts
Statistics	The dataset publisher, not the article citing it

Use web_fetch on the source URL to pull the page as clean Markdown (pass the raw URL — don't hand-build a r.jina.ai/ prefix). When the source is behind a login, renders via JS, or blocks fetching, switch to browser per web-access.

When no official source exists, an original report from an authoritative outlet (not a reprint) can serve as a secondary basis — but say so explicitly: "No official source found; the following relies on [outlet]'s reporting and may carry transcription error."

3. Adversarial verify — try to break each claim

This is what separates research from a summary. For each load-bearing claim, run a skeptical pass before trusting it:

• Does the source actually say this, or is it the article's spin on it?
• Is the source primary, or is it echoing someone else? Trace one hop back.
• Is it current, or superseded? Note the date on every source.
• Do independent sources disagree? Surface the disagreement — don't average it away.

For high-stakes claims, dispatch a verifier sub_agent prompted to refute the claim (default to "unverified" when uncertain), not to confirm it. A claim that survives an honest attempt to break it is worth reporting; one that doesn't gets dropped or flagged as contested.

Track claim → source as you go. Anything you can't attribute to a source you read does not enter the report as fact — at most as a clearly-labelled open question.

4. Synthesize — the cited report

Structure to the deliverable from step 0, not a fixed template. Typical shape:

• Bottom line — the answer to the question, up front, in a few sentences.
• Findings — organized by sub-question or theme, each key claim carrying an inline source (title + URL). Present genuine disagreement as disagreement.
• Confidence & gaps — what's well-established, what's thin or single-sourced, what you couldn't resolve. State this honestly; a known gap is more useful than false certainty.
• Sources — the primary sources you actually read, deduped.

Then check the report against the step-0 acceptance line. If it doesn't answer the question, name what's still missing rather than padding.

Completeness check

Before finishing, ask: what's missing? A sub-question not run, a claim asserted but never traced to a source, a contradiction glossed over, a source cited but not read. Whatever that surfaces is the next round — loop back to step 1 for it, don't ship around it. Stop when the acceptance criterion is met, not before, and don't over-research past it.