Deeply analyze a research topic, paper, method family, or technical direction to determine what actually works, under which assumptions, where the approach breaks, and what is still uncertain. Trigger when the user wants a serious research investigation rather than a summary, including prompts about understanding a paper, comparing methods, evaluating a direction, checking whether an approach is worth trying, identifying assumptions or failure modes, or deciding what to take into work. Do not summarize passively. Formalize the problem, build a taxonomy of approaches, extract assumptions, identify fragile claims, compare with adjacent methods, and produce an evidence-based conclusion: what to adopt, what not to adopt, and what remains unknown. Use subagents for bounded literature or documentation exploration when the topic is broad. Do not use for casual overviews, translation, shallow explainers, or repository-local code analysis.
Turn a vague research question into an evidence-oriented technical assessment.
This skill is for:
The goal is not to retell the source material. The goal is to determine:
Use this skill when the user wants to:
Typical trigger phrases:
Do not use this skill for:
Expected inputs:
Optional inputs:
Always produce:
Formalize the actual problem. Before discussing methods, define:
If the user's downstream use case is known, specialize the analysis to that setting.
Identify the object of analysis. Determine whether the request is about:
Build a taxonomy. Organize the relevant approaches into a compact structure. The taxonomy should reflect meaningful distinctions, such as:
The taxonomy must help explain why methods differ, not just list names.
Extract assumptions. For each main approach, identify:
Mark which assumptions are essential and which are merely convenient.
Identify what actually drives success. Separate:
Ask whether the apparent gain is due to the method itself or to surrounding setup.
Enumerate failure modes. For each relevant approach, identify:
Prefer concrete failure modes over vague caveats.
Compare with adjacent methods. Explicitly compare the target approach with neighboring alternatives. For each comparison, state:
Audit claims. For important claims, classify them as:
Be especially suspicious of claims about:
Translate to experiments. Propose the smallest useful set of experiments needed to validate applicability. Prefer experiments that test:
Make the experiments diagnostic, not decorative.
Produce the final decision. End with:
Use subagents only when the topic is broad enough that bounded exploration helps:
Each subagent must return a compact memo. The main thread should synthesize the memos into one judgment.
Do not use subagents for a narrow single-paper read unless the topic is unusually dense.
If a reusable custom subagent is available, prefer research-scout for bounded evidence collection.
Do not equate a paper claim with reality. Treat every major claim as conditional on assumptions, setup, and evaluation quality.
Always translate the method into the user's likely deployment or experiment setting. A method can be strong in general and still wrong for the actual use case.
Never analyze a method in isolation if meaningful neighboring baselines or alternatives exist.
If performance appears to depend heavily on scaling, data curation, tricks, or evaluation choices, say that explicitly instead of attributing the result to the core idea.
Prefer 2-4 diagnostic experiments that answer real uncertainties over a broad but shallow experiment list.
Use the supporting references when needed:
references/deep-dive-template.mdreferences/claims-audit-checklist.mdreferences/adjacent-method-comparison-template.mdreferences/diagnostic-experiments-template.mdReturn the final result in this structure:
Use this skill for:
Do not use this skill for: