git:20260701.b9c1253 to git:20260807.938c3fd

---

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 |

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.