메뉴
Use when a research task requires iterative depth -- goes beyond single-pass research with a 7-phase methodology that includes gap analysis, targeted follow-up, adversarial review, and convergence checking
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | deep-research |
| description | Use when a research task requires iterative depth -- goes beyond single-pass research with a 7-phase methodology that includes gap analysis, targeted follow-up, adversarial review, and convergence checking |
| allowed-tools | Read Grep Glob WebSearch WebFetch Agent |
TTD-DR (Test-Time Deepen -- Deep Research). An iterative research methodology that goes beyond "search and summarize" by adding gap analysis, targeted follow-up, adversarial critique, and convergence scoring. Seven phases, repeated until the research is deep enough or the iteration budget runs out.
This is a research methodology, not a search tool. Apply it by structuring how you approach complex questions -- decomposing them, identifying gaps in your knowledge, filling those gaps, and stress-testing your conclusions before delivering.
Threshold rule: If you can answer confidently and comprehensively in a single pass, do that. Deep research adds value only when the question genuinely benefits from iteration.
Phase 1: CLARIFY --> Decompose question, define "done"
Phase 2: DRAFT --> Initial broad research pass
Phase 3: GAP ANALYSIS --> Identify what's missing or uncertain
Phase 4: TARGETED RESEARCH --> Go deep on specific gaps
Phase 5: REFINE --> Synthesize all findings into coherent narrative
Phase 6: RED TEAM --> Adversarial review -- challenge every claim
Phase 7: CONVERGE --> Final synthesis with confidence levels
|
+---> Score quality 0-10
| Score >= target? --> Deliver
| Score < target? --> Loop back to Phase 3
+---> Max iterations reached? --> Deliver with quality notes
Decompose the question before researching. Do not start gathering information until you know what you are looking for.
Produce a research brief:
Example:
User question: "Should we migrate from REST to GraphQL?"
Research brief:
Core question: What are the technical and organizational trade-offs of
migrating an existing REST API to GraphQL for our use case?
Sub-questions:
1. What performance differences exist (latency, payload size, caching)?
2. What is the migration cost (developer time, tooling, training)?
3. What operational risks exist (monitoring, debugging, security)?
4. What do teams who have done this migration report in retrospect?
5. Are there hybrid approaches that capture benefits without full migration?
Completion criteria:
- Each sub-question has at least 2 supporting sources
- Contradicting viewpoints are presented for trade-offs
- A clear recommendation framework (not just "it depends")
Initial research pass. Cast a wide net across available sources.
Sources to use (adapt to your context):
Rules for the draft:
[NEEDS VERIFICATION]Read the draft critically against the research brief. Identify what is missing, uncertain, or contradictory.
Produce a gap list (max 5 gaps per iteration):
[
{
"question": "What is the P99 latency difference between REST and GraphQL for nested queries?",
"importance": "high",
"section": "Performance Comparison"
},
{
"question": "How does GraphQL affect API caching strategies (CDN, HTTP cache)?",
"importance": "high",
"section": "Operational Considerations"
},
{
"question": "What percentage of teams report regretting the migration?",
"importance": "medium",
"section": "Industry Experience"
}
]
Importance levels:
If no gaps are found, the research has converged -- skip to Phase 7.
Research each gap individually. This is where depth comes from -- focused investigation of specific unknowns rather than broad surveys.
For each gap:
Parallel execution: Gaps are independent -- research them in parallel when possible (use subagents or multiple search passes).
Track facts as you go:
{
"content": "GraphQL queries with 3+ levels of nesting show 15-40% higher latency than equivalent REST calls",
"source": "https://engineering.shopify.com/blogs/engineering/...",
"confidence": 0.8,
"is_disputed": true,
"supporting_facts": ["Netflix benchmark showed similar results"],
"contradicting_facts": ["Apollo team claims <5% difference with DataLoader"]
}
Integrate new findings from Phase 4 into the draft.
Refinement rules:
[NEEDS VERIFICATION] tags where findings provide answersDo not just append findings -- weave them into the narrative so the final output reads as a cohesive document.
Adversarial critique of the refined draft. Deliberately try to break your own work.
Challenge the draft on:
Produce a critique list (max 5 issues):
[
{
"issue": "Performance comparison relies entirely on synthetic benchmarks, no production data cited",
"severity": "major",
"suggestion": "Add real-world migration case studies with production metrics"
},
{
"issue": "Security section does not address GraphQL-specific attack vectors (query complexity, batching)",
"severity": "critical",
"suggestion": "Add subsection on GraphQL security considerations: depth limiting, query cost analysis"
}
]
Severity levels:
Score the draft and decide whether to iterate or deliver.
Scoring rubric (0-10):
| Dimension | Weight | What to Check |
|---|---|---|
| Completeness | 0-2 | Does it answer all sub-questions from the brief? |
| Accuracy | 0-2 | Are claims well-supported with credible sources? |
| Depth | 0-2 | Is the analysis thorough beyond surface-level? |
| Structure | 0-2 | Is it well-organized and readable? |
| Balance | 0-2 | Are multiple perspectives and counterarguments covered? |
Total: 0-10
Convergence rules:
Default settings:
Research is "deep enough" when any of these conditions is met:
When delivering before full convergence, always note:
The final deliverable is a structured report:
# [Research Question]
## Summary
[2-3 sentence executive summary with the key finding/recommendation]
## Findings
### [Section 1 from brief]
[Content with inline source citations]
### [Section 2 from brief]
[Content with inline source citations]
...
## Confidence Assessment
| Finding | Confidence | Basis |
|---------|-----------|-------|
| [Key finding 1] | High (0.9) | Multiple concordant sources |
| [Key finding 2] | Medium (0.6) | Limited data, single source |
| [Key finding 3] | Low (0.4) | Contradictory sources, no consensus |
## Sources
1. [Source title](url) -- Used for: [what it supported]
2. [Source title](url) -- Used for: [what it supported]
## Remaining Uncertainties
- [Question that could not be fully resolved]
- [Area where more research would help]
## Methodology
- Iterations: [N]
- Final quality score: [X]/10
- Phases completed: [list]
- Total sources consulted: [N]
For large research tasks, use a supervisor/worker architecture:
Supervisor (you or the orchestrating agent):
Workers (subagents or focused research passes):
This separation ensures the supervisor maintains the big picture while workers go deep on specifics. Workers do not need to know about the overall iteration state -- they receive focused prompts and return focused results.
Not all sources are equal. Evaluate source quality at each phase:
| Source Type | Reliability | Use For |
|---|---|---|
| Primary research (papers, benchmarks, official docs) | High | Core claims, quantitative data |
| Industry case studies (engineering blogs from known companies) | Medium-High | Real-world validation, practical insights |
| Expert commentary (conference talks, interviews) | Medium | Perspective, interpretation |
| General articles (news, blog posts) | Medium-Low | Background context, trend signals |
| Forum discussions (Stack Overflow, Reddit) | Low-Medium | Anecdotal evidence, edge cases |
| AI-generated content (other LLM outputs) | Low | Treat as unverified claims |
Rules:
Question: "What are the security implications of using WebAssembly in production web applications?"
Phase 1 -- Clarify:
Phase 2 -- Draft:
[NEEDS VERIFICATION] on specific CVE counts, no data on server-side Wasm securityPhase 3 -- Gap Analysis:
Phase 4 -- Targeted Research:
Phase 5 -- Refine:
[NEEDS VERIFICATION] tagsPhase 6 -- Red Team:
Phase 7 -- Converge:
| Pattern | How It Uses Deep Research |
|---|---|
| OORT Cascade | Deep research is the Researcher role's methodology within a cascade |
| Compute Adaptation | At LOW tier, reduce max iterations; at CRITICAL, skip red-team phase |
| Audit Ledger | Each phase appends a ledger entry; iteration count and score tracked |
| Constitutional AI | no_hallucination rule reinforces source-backed claims |
| If you notice... | The problem is... | Fix it by... |
|---|---|---|
| Phase 2 draft is 5000 words with no sources | Writing an essay, not researching | Requiring inline citations for every factual claim |
| Phase 3 always finds 5 gaps | Generating gaps to fill the quota | Only listing genuine gaps; empty list means convergence |
| Phase 4 finds the same information as Phase 2 | Gaps are not specific enough | Writing gap questions as precise, answerable queries |
| Phase 6 red team always says "looks good" | Rubber-stamp critique | Requiring the red team to find at least 1 issue or explicitly justify why none exist |
| Score never reaches target after 4 iterations | Target is too high or question is inherently uncertain | Delivering with a quality note; some questions do not have clean answers |
| Every question gets 7-phase treatment | Over-engineering simple lookups | Using the "When NOT to Use" criteria to route simple questions to direct answers |
| Sources are all from the same domain/perspective | Research bias | Explicitly seeking contradicting viewpoints and alternative perspectives |
Use after completing a major work batch (plan execution, feature build, multi-task subagent run) to refresh code-graph-derived data in MEMORY.md/CONTEXT.md/SKILL_MEMORY, append dated narrative entries to TODO/CHANGELOG/lessons-learned, mine cross-project structural habits, and ratchet reusable permissions to global settings. Keeps project DNS in sync with reality.
Use when orchestrating multiple ghengis-skills across a single task -- coordinates pre-action validation, execution, post-action verification, and lesson extraction via a shared JSON scratchpad. TRIGGER when dispatching a subagent, finishing a major task, or when the user mentions "run the full chain", "validate this", "fire the pipeline", or explicitly invokes a chain by name.
Use to build and maintain an evolving understanding of user preferences, communication style, and working patterns — learns from interactions and adapts behavior over time
Use when starting a new project or organizing an existing one — creates self-documenting 4-layer project structure with MEMORY.md, CONTEXT.md, modular CLAUDE.md, and workspace routing
Use to accumulate and retrieve domain knowledge from past tasks — builds a grepable plain-text knowledge base that grows over time, enabling agents to learn from experience without vector databases
Use when reorganizing an existing project's file tree based on what actually connects to what — analyzes import graph, classifies layers, proposes an ideal target tree, validates the plan adversarially, then executes file moves with atomic per-language import rewrites. Always plan-first; never moves a file before the user confirms. TRIGGER on "reorganize this project", "clean up the file tree", "the structure is a mess", "make this match a real project layout", or after project-scaffold detects layout drift.