---
name: valtterimelkko/deep-research
source: https://app.decimal.ai/s/valtterimelkko-deep-research@1/SKILL.md
source_sha256: c90c5d1c7df2
---

# Deep Research Skill

A comprehensive workflow for conducting **broad, source-rich, auditable research** using iterative waves of subagents.

**Time**: ~6–10 minutes  
**Sources**: 40–100+  
**Best for**: academic rigor, due diligence, comparative analysis, high-stakes synthesis

The strength of this skill is **breadth with control**: it covers many dimensions without letting any single subagent become the whole research system.

---

## Core Operating Model

The main agent is the **research conductor**.

Subagents are used for:
- scouting source landscapes
- analysing curated source batches
- resolving contradictions
- checking synthesis quality

The main agent is responsible for:
- defining dimensions
- maintaining the research manifest
- maintaining the blocked-source registry
- curating which sources get promoted to deeper analysis
- deciding whether the research is sufficient
- consulting the user on fallback options when high-value blocked sources remain

### Core Principles

1. **Breadth is preserved at the workflow level, not overloaded into each subagent.**
2. **Subagents must return useful findings in their response text first.** File writes are secondary.
3. **Subagents must not silently switch to non-default fallback workflows** such as browser automation. If blocked, they must report and move on.
4. **Forward progress is preferred unless a critical gap is identified.**
5. **Blocked-source review happens at the end of the standard workflow**, before considering fallback workflows.
6. **Fallback workflows require explicit user consultation.**

---

## Research Tier Positioning

Use this skill as the **heaviest general-purpose research tier**:

1. **Native `web_search` / `web_fetch`** — one-off current facts, a single page, or a few URLs
2. **`gpt-research`** — quick / medium-depth synthesis across roughly 10-20 sources
3. **`deep-research` (this skill)** — 40+ sources, explicit methodology, high-stakes synthesis
4. **Specialised recency skills** such as `last30days` — when the main need is recent discourse across social/web platforms rather than broad general-web synthesis

If the user simply says “research this”, reserve this skill for tasks where the consequence of missing a dimension is materially important.

## When to Use This Skill vs Fast Research

### Use deep-research when:
- the user needs **40+ sources**
- the topic has **multiple dimensions that must all be covered**
- source quality and traceability matter
- the work is for publication, due diligence, or high-stakes decision-making
- the user explicitly wants a transparent, auditable methodology

### Use fast research instead when:
- the user wants a quick overview
- 10–20 sources are enough
- the topic is exploratory rather than high-stakes
- speed matters more than exhaustive coverage

---

## The Workflow

## Phase 0 — Preflight and Planning

### Goal
Validate that the normal research path is viable, then define the scope.

### Main agent actions
1. Analyse the user’s actual decision or question.
2. Break the topic into 4–8 research dimensions.
3. Identify the **key questions**, likely **source classes**, and any obvious **edge cases / blind spots**.
4. Draft **5–10 initial search queries or search angles** spanning the most important dimensions.
5. Run a **small preflight check** using the standard acquisition path to see whether search/fetch is broadly working.
6. Create a **Research Manifest** in your own notes / working state.

### Research Manifest (minimum fields)
Track at least:
- dimension name
- scout assigned
- scout result status
- analyst assigned
- analyst result status
- blocked-source count for the dimension
- whether the dimension is adequately covered

Do **not** turn the manifest into bureaucratic overhead. It is a lightweight control table.

---

## Phase 1 — Scout Wave (broad, lightweight)

### Goal
Cast a wide net cheaply and safely.

### Rule
**Scouts are discovery agents, not full analysts.** They should identify promising sources and report them compactly.

### Spawn
Launch 3–6 parallel scout agents, each covering a distinct dimension or source class.

Examples:
- official / regulatory
- academic / technical
- industry / practitioner
- news / current developments
- community / user sentiment
- regional / local angle

### Scout task shape
Each scout should:
- identify **6–10 promising sources**
- give a **1-line relevance note** for each
- estimate credibility at a high level
- capture **publication date / recency** when visible
- suggest **follow-up queries** if coverage looks thin or skewed
- report blocked URLs if encountered
- avoid deep extraction
- avoid contradiction resolution unless extremely obvious

### Mandatory scout instructions
Use wording along these lines:

```text
Use your default acquisition path only.
Do NOT invoke browser automation, playwright, or other non-default fallback workflows.
Browser automation is NOT a bot-protection bypass strategy in this workflow.
If a source is blocked by Cloudflare, anti-bot protection, rate limits, login walls, paywalls, or fetch failures, record the exact URL, barrier type, source class, and failure reason, then continue.
Your primary deliverable is this response text. File writes are optional secondary artifacts.
At the end, explicitly report:
- created_files: [...]
- modified_files: [...]
- blocked_urls: [{url, barrier_type, reason, source_class}]
- unblocked_sources: [{title, url, publication_date_or_recency, relevance_note, credibility_estimate}]
- follow_up_queries: [...]
If no files were created, say so explicitly.
```

### Preferred scout output format

```markdown
## Scout Summary
Dimension: [name]
Status: adequate | thin | blocked-heavy

## Candidate Sources
1. [Title] — URL
   - Relevance: ...
   - Credibility: High/Medium/Low
   - Date/Recency: ...

## Follow-up Queries
- ...

## Blocked URLs
- URL — barrier type — reason

## Files
- created_files: [...]
- modified_files: [...]
```

### Main agent after scouts
1. Read all scout outputs.
2. Deduplicate sources.
3. Update the manifest.
4. Build a **Blocked Source Registry**.
5. Promote the strongest sources into curated analyst batches.

---

## Phase 2 — Analyst Wave (narrower, heavier)

### Goal
Do the deep reading and extraction on curated source batches.

### Rule
**Analysts receive curated URLs.** They should not wander broadly. However, if a curated batch is missing a necessary primary source, a key dissenting source, or another narrowly defined source needed to evaluate a material claim, the analyst may add **up to 1–2 tightly scoped supplementary sources** and must label them clearly as supplementary recovery sources.

### Batch size
Give each analyst **~4–7 URLs** or a similarly narrow, clearly bounded source batch.

### Analyst responsibilities
Each analyst should:
- extract key findings
- identify areas of consensus and disagreement
- note methodological caveats
- flag weak or suspicious sources
- apply a **compact source-verification checklist** to material sources: author/organisation, date/recency, source type, primary-vs-secondary, methodology present/absent when relevant, obvious bias/conflict flags, and whether the claim was cross-checked
- report blocked URLs if any curated sources fail
- propose **follow-up queries** if a material gap remains
- return structured markdown in response text first

### Mandatory analyst instructions
Use wording along these lines:

```text
Use your default acquisition path only.
Do NOT invoke browser automation, playwright, or other non-default fallback workflows.
Browser automation is NOT a bot-protection bypass strategy in this workflow.
If any curated URL is blocked or fails to load, report it exactly and continue with the remaining sources.
Do not broaden scope unless explicitly instructed, except for at most 1–2 tightly scoped supplementary recovery sources when needed for a material claim.
Your primary deliverable is this response text. File writes are optional secondary artifacts.
At the end, explicitly report:
- created_files: [...]
- modified_files: [...]
- blocked_urls: [{url, barrier_type, reason, source_class, estimated_importance}]
- supplementary_sources: [{title, url, why_needed}]
- follow_up_queries: [...]
```

### Preferred analyst output format

```markdown
## Analyst Findings
Batch: [name]
Coverage: strong | moderate | weak

## Key Findings
- ...

## Important Claims and Support
- Claim: ...
  - Sources: ...
  - Cross-check status: ...

## Source Verification Notes
- Source: ...
  - Author/Organisation: ...
  - Date/Recency: ...
  - Type: primary / secondary / commentary
  - Methodology present?: yes/no/not applicable
  - Bias/conflict notes: ...

## Caveats / Contradictions
- ...

## Supplementary Recovery Sources
- ...

## Follow-up Queries
- ...

## Blocked URLs
- URL — barrier type — reason — estimated importance

## Files
- created_files: [...]
- modified_files: [...]
```

---

## Phase 3 — Synthesis and Gap Resolution

### Goal
Turn analysed batches into a coherent answer.

### Main agent actions
1. Group findings into themes.
2. Identify what is already adequately covered.
3. Identify only the most important remaining gaps.
4. If substantive disagreement appears on a material claim, spawn a **targeted contradiction-resolution deep dive** before treating that claim as high-confidence.
5. Spawn other targeted deep-dive agents only where necessary.

### Use additional deep-dive agents for:
- contradiction resolution
- missing official / survey evidence
- missing primary / seminal / uniquely probative evidence
- regional gaps
- terminology or methodology clarification

### Do not spawn another broad scout wave unless:
- a major dimension is still under-covered, or
- the user explicitly asks for more breadth

---

## Phase 4 — QA and Sufficiency Check

### Goal
Decide whether the research is strong enough to stand on its own.

### Main agent checks
- Are all key dimensions covered?
- Are the strongest claims supported by credible sources?
- Are the blocked sources material to the conclusions?
- Is the evidence set broad enough to answer the original prompt faithfully?

### QA micro-checklist
Before finalising, explicitly check:
- Are any **material claims** unsupported, weakly supported, or supported only by low-credibility sources?
- Do the **citations actually support the claims** they are attached to?
- Were **substantive contradictions** either resolved through targeted follow-up or clearly carried forward as uncertainty/contestation?
- Are any high-confidence conclusions relying on evidence that should instead be framed as tentative?

### Prefer forward progress
Do not keep digging forever. Move toward report assembly unless a **critical gap** remains.

---

## Phase 5 — Blocked Source Review (end of normal workflow)

This happens **after** the standard workflow is complete, not mid-workflow.

### Goal
Assess whether blocked/failed sources materially weaken the result.

### Maintain a Blocked Source Registry
Track, at minimum:
- URL
- source class (official / major survey / academic / technical doc / practitioner / media / community / aggregator / other)
- dimension
- barrier type / failure reason
- evidentiary role (official, major survey, primary study, seminal paper, benchmark doc, canonical technical documentation, practitioner evidence, commentary, other)
- whether an equivalent unblocked source was found
- replaceability (high / medium / low)
- estimated importance

### Importance rubric
Class blocked sources as:
- **Critical** — sources whose absence materially weakens the conclusion because they are official, major-survey, primary, seminal, uniquely probative, or otherwise not adequately replaceable
- **Important** — strong sources that materially improve confidence or breadth, but are replaceable with some loss of fidelity
- **Peripheral** — useful but non-essential

### Default threshold for stronger fallback recommendations
Recommend stronger fallback options primarily when blocked sources include:
- **official sources**, and/or
- **major survey sources**
that are not adequately replaced by unblocked alternatives

Also consider stronger fallback recommendations when blocked sources are:
- **primary or seminal sources** central to a key claim
- **canonical technical documentation / benchmark pages** needed to verify an important claim
- **uniquely relevant regional or practitioner evidence** with no good unblocked substitute

### End-of-workflow blocked-source analysis
Report to the user:
- number of blocked URLs
- blocked-source count by source class
- which dimensions were affected
- whether the blocked sources are critical, important, or peripheral
- whether the current research is still sufficient without them
- which blocked sources are likely replaced well vs poorly replaced

Do **not** dump a giant raw URL list into the final user-facing summary unless asked.

---

## Fallback Workflows (only after standard workflow ends)

Fallback workflows are considered **only at the end** of the normal deep-research workflow.

## Fallback A — Camofox targeted recovery (free, local, preferred first)

Recommend **`camofox`** first when blocked sources remain important and the problem looks like a browser-style anti-bot / JS-rendering barrier, especially when:
- a **small number of high-value URLs** are blocked
- the blocked pages are public but hidden behind Cloudflare, challenge pages, blank JS rendering, or similar anti-bot friction
- recovering those pages would materially improve confidence in one or more important claims

### Camofox rules in this workflow
- Use it only for **targeted recovery of specific blocked URLs**, not as a silent background path for every scout or analyst
- The **main agent** should decide which blocked URLs are worth recovery after blocked-source analysis
- Recover the smallest useful set first: official pages, major surveys, canonical documentation, or other poorly replaceable sources
- If Camofox fails, keep the evidence gap visible and only then consider higher-friction fallbacks

## Fallback B — NotebookLM (user-participatory broad recovery)

Recommend NotebookLM when blocked sources remain important and the recovery problem is broad rather than a short list of individual pages, especially when:
- the blocked material spans a **broad topic**
- several blocked URLs affect the same dimension or subtopic
- the user is comfortable doing a login step and wants a lower-barrier recovery path

NotebookLM is usually the next fallback when the blocked problem is broad or when multiple important blocked URLs can be recovered through a user-participatory notebook workflow.

### Two NotebookLM patterns

#### 1. Broad-topic recovery
Use NotebookLM to perform deep research on:
- the same topic, or
- a narrower blocked subtopic

This is appropriate when blocked coverage affects a broad slice of the research.

#### 2. Narrow-source recovery
If only a modest number of blocked URLs matter, recommend adding those URLs directly as notebook sources, then querying the notebook.

### Important NotebookLM notes
- Requires user login / session participation
- Treat NotebookLM as a **recommended fallback**, not an autonomous silent fallback
- It is best used as a **recovery and synthesis aid**, not as a perfect substitute for direct fetch
- For technical details and commands, **read the `notebooklm` skill**

## Fallback C — Residential Proxy (higher barrier; explicit permission only)

Recommend residential proxy only when:
- blocked sources are **high-value**, especially official or major-survey sources
- or the blocked sources are **critical primary / seminal / uniquely probative sources** that are poorly replaceable
- the gaps materially weaken the research
- the user explicitly authorizes the proxy path

### Residential proxy policy
- **Never use it without explicit user permission**
- Estimate **data volume bands**, not exact cost:
  - small batch
  - medium batch
  - large batch
- Explain why the blocked sources are important enough to justify it
- For technical details, **read the `residential-proxy` skill**

---

## Retry Policy

### Default bias
Prefer **balanced forward progress**:
- move on unless a critical gap is identified
- do not let one blocked source stall the whole workflow

### Recommended retry behavior
- **Blocked / anti-bot / rate-limit / login-wall / paywall failure**: do not retry with browser automation, Playwright, or other non-default acquisition tools; log the barrier type and continue
- **Formatting / malformed output failure**: 1 retry with simpler output requirements
- **Thin scout results**: 1 narrower retry if the dimension still matters
- **Repeated failure**: mark the dimension as thin or blocked-heavy and proceed

---

## Final Report Requirements

The final report should include all of the following:

1. **Blocked-source statistics**
2. **Blocked-source importance analysis**
3. **Confidence statement**
4. **Fallback recommendations** (if relevant)
5. **Methodology limitations stated up front**, not buried only in an appendix
6. **References section** for sources actually used in the report
7. **Source inventory appendix or machine-readable source list** covering the consulted evidence base

Major claims in the final report should be traceable to cited sources. Do not rely on uncited synthesis for material conclusions.

### Recommended methodology summary table
Include a concise methodology / limitations table in the final report, for example:

| Item | Status |
|------|--------|
| Dimensions covered | X / Y |
| Sources used | N |
| Blocked URLs | N |
| Critical blocked sources | N |
| Research confidence | High / Medium / Low |
| Fallback recommended | None / Camofox / NotebookLM / Residential proxy |

---

## Common Pitfalls to Avoid

1. **Overloading scouts** with deep extraction and formatting duties
2. **Losing findings because file writes failed**
3. **Silent browser/playwright fallback** that creates hidden artifacts without helping
4. **Treating all blocked URLs as equally important**
5. **Raw-appending research files into the final report** instead of synthesizing them cleanly
6. **Letting blocked-source analysis derail the standard workflow too early**
7. **Burying major methodology limitations in appendices only**
8. **Letting curated analysts become broad scouts again** instead of using only narrow recovery where truly needed
9. **Dropping source traceability** because the prose sounds confident

---

## Summary

This skill wins by keeping the **overall workflow broad** while making each subagent more focused and auditable.

Use broad scouting first, promote the best sources into deeper analysis, keep a clear blocked-source registry, and only consider fallback workflows after the normal research pass is complete.

**Default stance:** keep moving, surface blocked-source significance clearly, try targeted `camofox` recovery before paid proxy escalation, and involve the user before using higher-friction fallback paths.