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; it fetches directly and extracts the main content for you. 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.