deep-dive
Skill5 starsChanged 8 months agoMITView on GitHub
Deep dive on any topic. Decomposes into subtopics, researches each in parallel with thorough source gathering, then synthesizes into a comprehensive report (4,000-10,000+ words, 40-100+ sources). Scales depth dynamically based on topic complexity. Use when asked for a deep dive, deep research, comprehensive analysis, or thorough investigation of a topic.
24 other projects use a version of this.
Adopted by
Most recently taken up by
- hom3bru/skill-belttheir own version, first seen Nov 8, 2026
- myths-labs/musetheir own version, first seen Nov 6, 2026
- okou-ai/okou-skillstheir own version, first seen Nov 4, 2026
- ZaxbyHub/opencode-swarmtheir own version, first seen Oct 30, 2026
- Joonghyun-Lee-Frieren/oh-my-antigravitytheir own version, first seen Oct 25, 2026
- xdanger/skillstheir own version, first seen Oct 20, 2026
Used with
Projects with it also use ralplan, deep-interview and 8 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ibahgatSkillralplan
Create a strict, quality-first execution plan with explicit gates and rollback-ready sequencing.
Also in 4 projects that use this
klauswgSkilldeep-interview
在明确批准执行之前,通过数学化歧义门控进行苏格拉底式深度访谈
Also in 3 projects that use this
thoughtbotSkilltrace
Run a scenario and record what actually happened.
Also in 3 projects that use this
sahinSkillexecute
Also in 4 projects that use this
snarktankSkillralph
Convert PRDs to prd.json format for the Ralph autonomous agent system. Use when you have an existing PRD and need to convert it to Ralph's JSON format. Triggers on: convert this prd, turn this into ralph format, create prd.json from this, ralph json.
Also in 3 projects that use this
nicolasestremSkillbrainstorm
Structured idea generation and solution exploration with systematic analysis.
Also in 4 projects that use this
Other versions24 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 24
- zereight/gitlab-mcp★ 2.1ksame name
- zaxbysauce/opencode-swarm★ 519same name
- ZaxbyHub/opencode-swarm★ 518same name
- Joonghyun-Lee-Frieren/oh-my-antigravity★ 214same name
- Joonghyun-Lee-Frieren/oh-my-gemini-cli★ 214same name
- okou-ai/okou-skills★ 81same name
- vm0-ai/vm0-skills★ 81same name
- myths-labs/muse★ 38same name
- joyehuang/skills★ 9same name
- bis-code/claude-toolkit★ 8same name
14 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- agent-commsSkill
- alexa-cliSkill
- app-screenshotsSkill
- branch-sessionSkill
- claude-session-handoffSkill
- project-spawnSkill
- skill-refactoringSkill
- todoist-cliSkill
- transcribe-and-analyzeSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. 0 are common, 18 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
18
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Before decomposing, assess the topic to determine how much research it warrants:
- Distinctive: line 38
User signal: If user says "quick" or "focused", go Focused.
- Distinctive: line 162
Wait for all agents to complete.
- Distinctive: line 174
Write the final report yourself (do NOT delegate synthesis to an agent).
- Distinctive: line 300
If you're more than 25% below your tier's word floor, go back and expand thin sections.
- Very specific: line 303
Every factual claim: must have an inline citation as text or (Source).
- Distinctive: line 306
Specificity: Use real names, real numbers, real dates.
- Distinctive: line 308
Readable structure: Use headers, sub-headers, tables, bullet lists, and bold text for scannability.
- Distinctive: line 309
No filler: Every paragraph must contain information or analysis.
- Distinctive: line 318
After saving, output a brief summary:
- Very specific: line 331
Do NOT create outline.yaml, fields.yaml, or per-item JSON files
- Distinctive: line 332
Do NOT create README, MANIFEST, or INDEX files
- Distinctive: line 333
Do NOT ask the user questions mid-research (decompose and go, only pause after Phase 1)
- Distinctive: line 334
Do NOT run agents sequentially -- launch all in parallel
- Distinctive: line 335
Do NOT just concatenate subtopic findings -- synthesize across themes
- Distinctive: line 336
Do NOT produce reports significantly below your tier's word floor -- that means insufficient research or lazy synthesis
- Distinctive: line 337
Do NOT use vague language when specific data exists -- find the number
- Distinctive: line 338
Do NOT skip WebFetch -- search result snippets alone are too shallow for deep analysis
- Distinctive: line 339
Do NOT settle for significantly fewer sources than your tier targets -- run supplementary agents if needed
- Distinctive: line 340
Do NOT pad word count with filler -- every paragraph earns its place with information or analysis
“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deep Dive
Produce comprehensive research reports by decomposing topics into subtopics, researching each in parallel with exhaustive source gathering, and synthesizing into a single deeply-analyzed report.
Trigger
/deep-dive <topic> or when user asks for a deep dive, deep research, or comprehensive analysis of a topic.
Phase 1: Scope and Decompose (do this yourself, no agent)
1a: Assess Topic and Set Research Tier
Before decomposing, assess the topic to determine how much research it warrants:
| Focused | Standard | Comprehensive | |
| When | Narrow comparison, specific technical question, well-defined scope | Most topics -- technology analysis, trend report, landscape overview | Broad survey, emerging field, multi-stakeholder analysis |
| Subtopics | 5-7 | 7-9 | 9-12 |
| Word target | 4,000-6,000 | 6,000-8,000 | 8,000-10,000+ |
| Source target | 40-60 | 60-80 | 80-100+ |
| Example | "WebTransport vs WebSockets" | "State of real-time web protocols in 2026" | "Complete guide to building real-time infrastructure" |
Choose the tier based on:
- Breadth: How many distinct dimensions does the topic have?
- Maturity: Established topics have more sources; emerging ones may max out at fewer
- Comparison surface: Binary comparisons need fewer subtopics than landscape surveys
- User signal: If user says "quick" or "focused", go Focused. If "comprehensive" or "exhaustive", go Comprehensive. Default to Standard.
1b: Interpret the Research Question
Determine:
- Scope: Is this a comparison, a landscape survey, a how-to, a trend analysis, or an investigation?
- Audience: Technical practitioners, executives, researchers, or general?
- Depth signals: What would a domain expert want to know that a surface-level article would miss?
1c: Generate Subtopics
Generate subtopics according to the selected tier. Each subtopic should be:
- Distinct (minimal overlap)
- Specific enough to yield targeted search results
- Substantial enough to produce 500-1500 words of findings (scale with tier)
Structure subtopics to cover these angles where relevant (not all will apply to every topic -- use judgment):
- History/Origins -- how did this emerge, key milestones, timeline
- Current State -- what exists today, major players, market landscape
- Technical Deep-Dive -- architecture, implementation details, how it actually works
- Comparisons/Alternatives -- head-to-head analysis, trade-offs, benchmarks
- Real-World Usage -- case studies, production deployments, who uses this and why
- Performance/Data -- benchmarks, metrics, quantitative evidence
- Limitations/Criticism -- what doesn't work, known issues, contrarian takes
- Economics/Business -- pricing, market size, business models, ROI
- Ecosystem/Tooling -- related tools, integrations, community
- Future Direction -- roadmaps, trends, predictions, open research questions
Output format:
Researching: {topic}
Tier: {Focused | Standard | Comprehensive}
Scope: {comparison | landscape | deep-technical | trend-analysis | investigation}
Targets: ~{N} words, {N}-{N} sources, {N} subtopics
Subtopics:
1. {subtopic_1} -- {why this angle matters}
2. {subtopic_2} -- {why this angle matters}
...Show this to the user before proceeding. If the user wants adjustments (including tier), incorporate them.
Phase 2: Parallel Research (launch ALL agents at once)
Launch agents simultaneously (one per subtopic) using the Agent tool with run_in_background: true.
Each agent must be a thorough researcher, not a skimmer. Use this prompt template:
You are a research specialist investigating ONE subtopic for a larger comprehensive report. Your job is to be EXHAUSTIVE -- find every important detail, data point, and perspective.
Main topic: {topic}
Your subtopic: {subtopic_N}
Why this matters: {subtopic_rationale}
## Research Process
### Step 1: Broad Search (5-7 queries)
Run 5-7 WebSearch queries with varied phrasings, angles, and specificity levels:
- 2 broad queries to find major sources
- 2 specific/technical queries for depth
- 1-2 queries targeting data, benchmarks, or statistics
- 1 query targeting criticism, limitations, or contrarian views
### Step 2: Deep Read (5-8 sources)
Use WebFetch on the 5-8 most substantive results. Prioritize:
- Primary sources (official docs, research papers, company blogs) over aggregators
- Sources with original data, benchmarks, or case studies
- Recent sources (last 12-18 months) for fast-moving topics
### Step 3: Follow-up Search (2-3 queries)
Based on what you learned in Steps 1-2, run 2-3 targeted follow-up searches to fill gaps:
- Names, projects, or tools mentioned in sources but not yet explored
- Statistics or claims that need verification from a second source
- Specific technical details that were referenced but not explained
### Step 4: Compile Findings
Return your findings as structured text. Be DETAILED -- aim for 800-1500 words of substance.
## {subtopic_N}
### Key Findings
- [finding with specific details] ([Source Title](url))
- [finding with data points] ([Source Title](url))
...
### Detailed Analysis
[4-8 paragraphs of thorough findings. Include:
- Specific numbers, dates, versions, metrics
- Named examples (companies, projects, people)
- Direct quotes where impactful
- Technical details where relevant
- Comparisons and context
Every claim must have an inline citation as [text](url).]
### Data Points & Evidence
[Bullet list of specific quantitative findings:
- Market size, growth rates, adoption numbers
- Performance benchmarks, speed comparisons
- Survey results, usage statistics
- Pricing, cost comparisons
Include source for each.]
### Contrarian Views & Limitations
[What are the criticisms, downsides, or alternative perspectives on this subtopic?]
### Sources (with annotations)
- [Title](url) -- what this source uniquely contributed
- [Title](url) -- what this source uniquely contributed
...
IMPORTANT: Target 8-15 unique, high-quality sources for your subtopic. Do NOT pad with low-value results.CRITICAL: Launch ALL agents in a single message so they run truly in parallel.
Phase 3: Collect and Audit
Wait for all agents to complete. Then audit the raw material:
- Source count check -- compare total unique URLs against your tier target. If you're more than 20% below target, identify the thinnest subtopics and run 1-2 supplementary agents to fill gaps.
- Quality check -- scan for agents that returned shallow results (under 300 words, fewer than 4 sources). Re-run those with more specific queries.
- Contradiction check -- note where agents found conflicting data. These become valuable discussion points in the report.
- Deduplication -- identify sources cited by multiple agents. These are likely the most authoritative -- weight them higher.
- Sufficiency check -- is the raw material enough to hit the word target? If total agent output is less than 1.5x the word target, the synthesis will be thin. Run supplementary agents on the weakest areas.
Phase 4: Synthesize the Report
Write the final report yourself (do NOT delegate synthesis to an agent). You have all the raw research -- now produce a report that rivals professional research output.
Report Structure
# {Topic}: A Comprehensive Analysis
> **Research Date:** {YYYY-MM-DD}
> **Sources Analyzed:** {N} unique sources across {N} subtopics
> **Word Count:** ~{N}
> **Method:** Multi-agent parallel research with {N} specialized research agents
---
## Table of Contents
[Auto-generated with anchor links to all sections]
---
## Executive Summary
[500-800 words. This should stand alone as a complete briefing. Cover:
- What this topic is and why it matters right now
- 5-7 key findings with the most important data points
- The central tensions/trade-offs discovered
- Bottom-line assessment or recommendation
- Who should care about this and what they should do]
---
## Background and Context
[Set the stage. History, origins, why this topic exists. Timeline of key milestones if relevant. Define key terms. 500-1000 words.]
---
## {Thematic Section 1}
[Organize by THEME, not by subtopic. Cross-reference findings from multiple research agents. Each section should be 800-1500 words with:
- Opening paragraph framing why this dimension matters
- Detailed findings with inline citations
- Specific examples, case studies, or data
- Comparison tables where relevant (use markdown tables)
- Sub-sections (###) for distinct aspects within the theme]
## {Thematic Section 2}
...
## {Thematic Section N}
[Typically 5-8 thematic sections for thorough coverage]
---
## Comparative Analysis
[If the topic involves alternatives, competitors, or approaches -- provide structured comparison:
- Markdown comparison table(s) with key dimensions
- Prose analysis of trade-offs
- Situational recommendations ("Use X when..., Use Y when...")]
---
## Data & Evidence Summary
[Consolidate the most important quantitative findings into a reference section:
- Key statistics and metrics in a scannable format
- Benchmark results if available
- Market data, adoption numbers, growth trends
- Use tables or bullet lists for scannability]
---
## Limitations, Criticisms, and Open Questions
[What the research revealed as unresolved, debated, or problematic:
- Known limitations of the technologies/approaches covered
- Active debates in the community
- Gaps in available data
- Questions that couldn't be fully answered]
---
## Future Outlook
[Where is this heading? Based on evidence found:
- Announced roadmaps or upcoming releases
- Trend lines from the data
- Expert predictions (cited)
- Emerging approaches or disruptors]
---
## Conclusions and Recommendations
[Actionable synthesis:
- Key takeaways (numbered list, 5-10 items)
- Specific recommendations based on different use cases/audiences
- What to watch for next]
---
## Sources
[Deduplicated, organized by section. Full list of every URL cited in the report.
Format: numbered list with title, URL, and brief annotation of what it contributed.
### {Section Name} Sources
1. [Title](url) -- contributed: {what}
2. [Title](url) -- contributed: {what}
...
### {Section Name} Sources
...]Synthesis Quality Standards
Scale with tier, but never compromise on signal density:
Length and source targets by tier:
| Focused | Standard | Comprehensive | |
| Words | 4,000-6,000 | 6,000-8,000 | 8,000-10,000+ |
| Sources | 40-60 | 60-80 | 80-100+ |
| Thematic sections | 3-5 | 5-7 | 6-9 |
If you're more than 25% below your tier's word floor, go back and expand thin sections. If you're below the source floor, run supplementary research.
Universal standards (all tiers):
- Every factual claim must have an inline citation as
[text](url)or([Source](url)). - Cross-referencing: Findings from one subtopic must inform analysis in other sections. Do not just concatenate agent outputs.
- Comparison tables: Include at least 1-2 structured comparison tables where the topic warrants it.
- Specificity: Use real names, real numbers, real dates. Vague statements like "many companies use this" are unacceptable -- name them.
- Balanced perspective: Include contrarian views, limitations, and criticism. One-sided analysis is shallow analysis.
- Readable structure: Use headers, sub-headers, tables, bullet lists, and bold text for scannability. Dense walls of text are a failure mode.
- No filler: Every paragraph must contain information or analysis. Remove throat-clearing, transitions-for-transitions-sake, and restating what was just said.
- Signal density over word count: A 5,000-word report packed with data and insight is better than a 10,000-word report padded with filler. Hit the target by going deeper, not wider.
Phase 5: Save
Save the report to the path the user specified. If no path specified, save to the current working directory as {date}-{topic-slug}.md.
After saving, output a brief summary:
Report saved: {path}
Words: ~{N}
Sources: {N} unique URLs
Sections: {N}
Research agents: {N}What NOT to Do
- Do NOT create outline.yaml, fields.yaml, or per-item JSON files
- Do NOT create README, MANIFEST, or INDEX files
- Do NOT ask the user questions mid-research (decompose and go, only pause after Phase 1)
- Do NOT run agents sequentially -- launch all in parallel
- Do NOT just concatenate subtopic findings -- synthesize across themes
- Do NOT produce reports significantly below your tier's word floor -- that means insufficient research or lazy synthesis
- Do NOT use vague language when specific data exists -- find the number
- Do NOT skip WebFetch -- search result snippets alone are too shallow for deep analysis
- Do NOT settle for significantly fewer sources than your tier targets -- run supplementary agents if needed
- Do NOT pad word count with filler -- every paragraph earns its place with information or analysis
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

