Deep research

Deep Research

Produce thorough, cited research reports from multiple web sources using firecrawl and exa MCP tools.

When to Activate

• User asks to research any topic in depth
• Competitive analysis, technology evaluation, or market sizing
• Due diligence on companies, investors, or technologies
• Any question requiring synthesis from multiple sources
• User says "research", "deep dive", "investigate", or "what's the current state of"

Web access

Use the firecrawl / exa MCP tools when they are configured — they give the best recall. The harness does not install either, so check what you actually have first: without them, run the same workflow on your CLI's built-in web search and fetch tools (in Claude Code, WebSearch / WebFetch). With no web access at all, say so instead of writing a report from memory — an uncited report is the failure mode this skill exists to prevent.

Workflow

Step 1: Understand the Goal

Ask 1-2 quick clarifying questions:

• "What's your goal — learning, making a decision, or writing something?"
• "Any specific angle or depth you want?"

If the user says "just research it" — skip ahead with reasonable defaults.

Step 2: Plan the Research

Break the topic into 3-5 research sub-questions. Example:

• Topic: "Impact of AI on healthcare"
  • What are the main AI applications in healthcare today?
  • What clinical outcomes have been measured?
  • What are the regulatory challenges?
  • What companies are leading this space?
  • What's the market size and growth trajectory?

Step 3: Execute Multi-Source Search

For EACH sub-question, search using available MCP tools:

With firecrawl:

firecrawl_search(query: "<sub-question keywords>", limit: 8)

With exa:

web_search_exa(query: "<sub-question keywords>", numResults: 8)
web_search_advanced_exa(query: "<keywords>", numResults: 5, startPublishedDate: "2025-01-01")

Search strategy:

• Use 2-3 different keyword variations per sub-question
• Mix general and news-focused queries
• Aim for 15-30 unique sources total
• Prioritize: academic, official, reputable news > blogs > forums

Step 4: Deep-Read Key Sources

For the most promising URLs, fetch full content:

With firecrawl:

firecrawl_scrape(url: "<url>")

With exa:

crawling_exa(url: "<url>", tokensNum: 5000)

Read 3-5 key sources in full for depth. Do not rely only on search snippets.

Step 5: Synthesize and Write Report

Structure the report:

# [Topic]: Research Report
*Generated: [date] | Sources: [N] | Confidence: [High/Medium/Low]*

## Executive Summary
[3-5 sentence overview of key findings]

## 1. [First Major Theme]
[Findings with inline citations]
- Key point ([Source Name](url))
- Supporting data ([Source Name](url))

## 2. [Second Major Theme]
...

## 3. [Third Major Theme]
...

## Key Takeaways
- [Actionable insight 1]
- [Actionable insight 2]
- [Actionable insight 3]

## Sources
1. [Title](url) — [one-line summary]
2. ...

## Research Ledger — [N] confirmed · [M] killed

| Killed claim/direction | Why rejected | Source that killed it |
|---|---|---|
| [what you looked into] | [contradicting evidence / legal or licensing block / vendor-only claim] | [url] |

> **Caveats**: [which numbers are vendor-promotional or self-reported, which sources are
> preprints, which claims you could not verify verbatim and are therefore follow-up work]

## Methodology
Searched [N] queries across web and news. Analyzed [M] sources.
Sub-questions investigated: [list]

The ledger is not optional

A report that lists only what survived hides the most reusable part of the work. Record it as N confirmed · M killed, and for each killed item write why — contradicting evidence, a legal block, or a claim that turned out to be vendor-promotional. Two things follow:

• Nobody re-researches a dead end. Next quarter the same idea resurfaces; the ledger answers it in one line instead of another research cycle.
• A kill count is evidence of rigor. 22 confirmed · 0 killed means you were collecting support, not testing claims. Zero kills is a signal to re-examine, not a clean result.

The caveat block does the same job for what survived but is weakly sourced: vendor numbers with no independent verification, preprints whose self-reported performance you cite architecture from but not results, beta APIs. Naming them keeps a soft source from hardening into a fact downstream.

Step 6: Deliver

• Short topics: Post the full report in chat
• Long reports: Post the executive summary + key takeaways, save full report to a file

Parallel Research with Subagents

For broad topics, use Claude Code's Task tool to parallelize:

Launch 3 research agents in parallel:
1. Agent 1: Research sub-questions 1-2
2. Agent 2: Research sub-questions 3-4
3. Agent 3: Research sub-question 5 + cross-cutting themes

Each agent searches, reads sources, and returns findings. The main session synthesizes into the final report.

Quality Rules

1. Every claim needs a source. No unsourced assertions.
2. Cross-reference. If only one source says it, flag it as unverified.
3. Recency matters. Prefer sources from the last 12 months.
4. Acknowledge gaps. If you couldn't find good info on a sub-question, say so.
5. No hallucination. If you don't know, say "insufficient data found."
6. Separate fact from inference. Label estimates, projections, and opinions clearly.

Examples

"Research the current state of nuclear fusion energy"
"Deep dive into Rust vs Go for backend services in 2026"
"Research the best strategies for bootstrapping a SaaS business"
"What's happening with the US housing market right now?"
"Investigate the competitive landscape for AI code editors"