Deep research skill that decomposes questions into parallel sub-queries, executes searches concurrently, selectively fetches high-value sources, and synthesizes structured answers with confidence ratings. Replaces slow sequential search-read-search loops with a planned, parallel-first methodology. Use when asked to "research", "deep dive", "investigate", "find out about", or any multi-source research task.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Deep research skill that decomposes questions into parallel sub-queries, executes searches concurrently, selectively fetches high-value sources, and synthesizes structured answers with confidence ratings. Replaces slow sequential search-read-search loops with a planned, parallel-first methodology. Use when asked to "research", "deep dive", "investigate", "find out about", or any multi-source research task.
license
Apache-2.0
metadata
{"author":"PHY041","version":"1.0.0","tags":["research","web search","deep dive","information retrieval","parallel search","synthesis","fact checking"],"triggers":["research","deep dive","investigate","find out about","what do we know about","gather information on","research deep"]}
Deep Research
Structured, parallel-first research methodology for AI agents. Turns vague questions into multi-source, evidence-backed answers in one pass instead of slow sequential search loops.
The Problem This Solves
Most AI agents research like this:
Search "X" → read result → realize they need Y → search "Y" → read →
realize they need Z → search "Z" → read → finally answer
= 6+ round trips, 3+ minutes, redundant reads
Any research task where sequential searching would be slow
When NOT to Use This Skill
Simple factual lookups (just use one WebSearch)
Questions answerable from the local codebase (use Grep/Glob instead)
Tasks requiring real-time data feeds or APIs (use the appropriate API)
Instructions
When a user asks you to research a topic:
Step 1: Decompose (Think Before Searching)
Break the question into 3-5 specific, non-overlapping sub-queries. Each sub-query should target a different facet of the question.
Rules:
Each sub-query must be a concrete search string, not a vague topic
Sub-queries should cover: definition/basics, current state, key players/examples, controversy/limitations, and future direction
If the user's question is already narrow, decompose by source type: official docs, community discussion, academic papers, news coverage
Example decomposition:
User asks: "Is WebAssembly ready for production server-side use?"
Sub-queries:
1. "WebAssembly server-side production 2026 case studies"
2. "WASI preview 2 stability limitations"
3. "WebAssembly vs containers performance benchmarks 2025 2026"
4. "Fermyon Cosmonic Wasmer production deployments"
5. "WebAssembly server criticisms problems developer experience"
Note: query 5 deliberately searches for the negative case. Always include at least one adversarial/critical sub-query to avoid confirmation bias.
Step 2: Parallel Search
Execute ALL sub-queries simultaneously using WebSearch. Do not wait for one result before starting the next.
# CORRECT: all in one message, parallel execution
WebSearch("WebAssembly server-side production 2026 case studies")
WebSearch("WASI preview 2 stability limitations")
WebSearch("WebAssembly vs containers performance benchmarks 2025 2026")
WebSearch("Fermyon Cosmonic Wasmer production deployments")
WebSearch("WebAssembly server criticisms problems developer experience")
# WRONG: sequential, one at a time
WebSearch("WebAssembly server-side") → read → WebSearch("WASI") → read → ...
Optional academic sources: If the topic has academic relevance, add an arxiv search in the same parallel batch. Not all topics need this — skip for product/market/community questions.
Step 3: Selective Fetch (Quality Over Quantity)
From all search results, pick only the 2-3 most information-dense sources to WebFetch. Do NOT fetch every result.
Selection criteria (pick sources that):
Contain original data, benchmarks, or primary research (not summaries of summaries)
Are from authoritative domains for the topic (official docs, known experts, peer-reviewed)
Were published recently (prefer last 12 months unless historical context needed)
Cover different angles (don't fetch 3 sources that say the same thing)
Skip fetching when:
The search snippet already contains the key fact you need
The source is a generic listicle or SEO-optimized filler article
You already have enough evidence for high-confidence conclusions
Step 4: Synthesize
Combine all findings into a structured output. Do NOT just list what each source said — synthesize across sources.
Output format:
## Research: [Topic]### Key Findings1.**[Finding 1]** (1-2 sentences)
- Evidence: [specific data point or quote] — [source]
- Evidence: [corroborating or conflicting data] — [source]
2.**[Finding 2]** - Evidence: ...
3.**[Finding 3]** - Evidence: ...
### Confidence Assessment
| Finding | Confidence | Basis |
|---------|-----------|-------|
| Finding 1 | High/Medium/Low | [why: e.g., "3 independent sources agree" or "single source, no corroboration"] |
| Finding 2 | ... | ... |
### Gaps & Unknowns- [What we could NOT find or verify]
- [Questions that remain open]
- [Potential biases in available sources]
### Sources- [Title](URL) — [one-line relevance note]
- [Title](URL) — [one-line relevance note]
Confidence Rating Guide
Level
Criteria
High
3+ independent sources agree, includes primary data or official documentation, no significant contradictions found
Medium
2 sources agree, or 1 highly authoritative source, minor contradictions exist but are explainable
Low
Single source only, or sources conflict significantly, or information is outdated (>12 months), or topic is rapidly evolving
Fix: Plan all queries in Step 1, execute in Step 2. If Step 2 reveals a completely unexpected angle, one additional targeted search is acceptable — but never more than one follow-up round.
Fix: Max 3 fetches. If you need more than 3, your sub-queries were too vague. Refine queries instead of fetching more pages.
3. The Summary-of-Summaries Trap
# BAD: "According to source 1... According to source 2... According to source 3..."
Fix: Synthesize across sources. Lead with the finding, then cite evidence from multiple sources inline.
4. The Missing Adversarial Query
# BAD: only searching for positive/confirming information
"X benefits", "X advantages", "X success stories"
Fix: Always include at least one query like "X problems", "X criticism", "X limitations", "X vs alternatives".
Example
User: "What's the current state of Rust in production web backends?"
Step 1 — Decompose:
1. "Rust web backend production 2026 companies using"
2. "Actix Axum web framework comparison benchmark 2025 2026"
3. "Rust backend developer experience hiring difficulty"
4. "Rust vs Go web server performance latency throughput"
5. "Rust web backend problems criticism compile time"
Step 2 — Parallel search (all 5 at once)
Step 3 — Selective fetch (pick best 2-3):
Official Rust survey 2025 results (primary data)
A detailed Axum vs Actix benchmark post (original benchmarks)
Skip: generic "Why Rust is great" blog posts
Step 4 — Synthesize:
## Research: Rust in Production Web Backends (March 2026)### Key Findings1.**Rust backend adoption is growing but remains niche** (~8-12% of new web projects)
- Evidence: Rust Survey 2025 shows 34% of respondents use Rust for web/networking, up from 28% — rust-lang.org
- Evidence: But Stack Overflow 2025 shows Rust at 8.2% for "used professionally" vs Go at 14.1% — stackoverflow.com
2.**Axum has emerged as the dominant web framework** - Evidence: Axum downloads surpassed Actix-web in Q3 2025, now 2.1x higher — lib.rs
- Evidence: Tokio ecosystem integration gives Axum a compounding advantage — shuttle.rs blog
3.**Hiring remains the primary blocker for teams considering Rust backends** - Evidence: "Finding Rust web developers is 3-4x harder than Go" — CTO interview, InfoQ 2025
- Evidence: Counterpoint — several companies report Rust attracts higher-quality candidates — r/rust
### Confidence Assessment
| Finding | Confidence | Basis |
|---------|-----------|-------|
| Growing but niche | High | Two independent surveys + download data |
| Axum dominant | High | Download metrics + ecosystem analysis |
| Hiring is blocker | Medium | Anecdotal (interviews), no systematic hiring data |
### Gaps & Unknowns- No reliable data on Rust backend failure/migration stories (survivorship bias)
- Limited information on Rust backend performance at >10K RPS in production
- Hiring difficulty may vary significantly by region (no geographic breakdown found)
Customization
This skill works with any search-capable tool. The core methodology (decompose → parallel search → selective fetch → synthesize) is tool-agnostic. Adapt the tool names to your environment:
Tool Category
Default
Alternatives
Web search
WebSearch
Any web search MCP tool
Page fetch
WebFetch
Any URL fetcher
Academic papers
arxiv MCP (optional)
Semantic Scholar, Google Scholar
Community sentiment
Reddit/HN search (optional)
Any forum search
Tips for Best Results
Time-bound your queries — Add the current year to searches to avoid stale results
Name specific entities — "Vercel Edge Functions cold start" beats "serverless performance"
Include version numbers — "React 19 server components" beats "React server components"
One follow-up max — If parallel results reveal a critical gap, one additional search round is acceptable. If you need two, your decomposition was wrong.
Cite inline — Every factual claim should have a source next to it, not in a separate section
