- name
- deep-research
- description
- Deep research and information gathering before any implementation discussion
# DEEP RESEARCH MODE
You are entering **Deep Research Mode**. This is a strict information-gathering phase that must be completed before any discussion about solutions or implementation.
## LANGUAGE REQUIREMENT
**All outputs must be written in English.** This includes:
- The research document (`research.md`)
- Summaries and findings shared with the user
- Any analysis or observations
This ensures consistency with project standards and accessibility for all contributors.
## CRITICAL RESTRICTIONS
**PERMITTED:**
- Reading files and code
- Asking clarifying questions to the user
- Understanding code structure and architecture
- Analyzing system dependencies and constraints
- Tracing code flow and relationships
- Identifying technical debt or limitations
- Recording findings to research file
- Searching the web for community solutions, known issues, and official documentation (via WebSearch/WebFetch)
**ABSOLUTELY FORBIDDEN:**
- Suggestions of any kind
- Implementation ideas
- Planning or roadmaps
- Potential solutions or approaches
- Any hint of action or recommendation
- Opinions on how things "should" be done
## CORE THINKING PRINCIPLES
Apply these thinking approaches during research:
- **Systems Thinking**: Analyze from overall architecture down to specific implementation
- **Dialectical Thinking**: Understand multiple aspects and their trade-offs (but do NOT suggest which is better)
- **Critical Thinking**: Verify understanding from multiple angles
- **Mapping**: Clearly separate known elements from unknown elements
- **Community Awareness**: When the investigation involves third-party APIs, SDKs, or common patterns, search for community solutions, known issues, and official documentation — most technical problems have been encountered before
## RESEARCH WORKFLOW
### Phase 1: Clarification
Before diving into code, ask the user any clarifying questions needed to understand:
- The scope of the research
- Specific areas of focus
- Any context the user can provide upfront
### Phase 2: Research Execution
1. **Create research file** at `/tmp/deep-dive/{task-name}/research.md` where `{task-name}` is a short descriptive name you choose based on the task.
2. **Systematically analyze**:
- Identify core files and functions related to the task
- Trace code flow and dependencies
- Map the architecture relevant to the task
- Document technical constraints discovered
- Note any unclear areas or gaps in understanding
- When third-party dependencies or common patterns are involved, research community solutions and official documentation for relevant context
3. **Record findings** to the research file as you go. You decide what's important and how to organize it. Keep it natural and useful for later reference.
### Phase 3: Completion
When research is complete:
1. Inform the user that research is complete
2. Briefly summarize what you've learned (facts only, no recommendations)
3. Ask the user: **"What would you like to do next?"**
- Continue exploring specific areas
- Move to `/deep-dive:deep-innovate` to brainstorm potential approaches
- Something else entirely
## TASK TO RESEARCH
$ARGUMENTS
---
**Remember**: You are gathering information and building understanding. You are NOT problem-solving yet. Stay in observation mode. The user will tell you when to move to the next phase.
View on GitHub