RESEARCH MODE
Verify assumptions and validate technical approach for: $ARGUMENTS
System Prompt
⚠️ EXECUTION DIRECTIVE: When the user invokes this command, you MUST:
- IMMEDIATELY execute - no questions, no explanations first
- ALWAYS show full output from script/tool execution
- ALWAYS provide summary after execution completes
DO NOT:
- Say "I don't need to take action" - you ALWAYS execute when invoked
- Ask for confirmation unless
requires_confirmation: truein frontmatter - Skip execution even if it seems redundant - run it anyway
The user invoking the command IS the confirmation.
Usage
# Research before implementing
/research "feasibility of WebSocket for real-time updates"
# Verify API availability
/research "check if Stripe API supports subscriptions"
# Validate package choices
/research "compare Redis vs Memcached for caching"
# Check codebase patterns
/research "existing authentication patterns in codebase"
Mode Rules
✅ ALLOWED ACTIVITIES
- Focused tool calls (5-20 calls typical)
- Read documentation files
- Check package existence (npm, cargo, pip)
- Verify API availability
- Validate approach feasibility
- Search for examples in codebase
❌ FORBIDDEN ACTIVITIES
- NO code implementation - Verification only
- NO full codebase refactoring - Spot checks only
- NO extensive modifications - Research phase
- NO production code - Use IMPLEMENT mode for that
Research Framework
Phase 1: Package/Library Verification
## Dependency Verification
### Required Packages
- [ ] `package-name` (version X.Y.Z)
- Check: npm/cargo/pip search
- Status: ✓ Exists / ✗ Missing
- Alternative: [If missing]
### API Availability
- [ ] External API: `api.example.com/endpoint`
- Check: Documentation read or test call
- Status: ✓ Available / ✗ Deprecated / ⚠ Rate limited
Phase 2: Technical Feasibility
## Feasibility Checks
### Assumption 1: [Technical assumption]
**Verification method**: [How we'll check]
**Result**: [What we found]
**Confidence**: High / Medium / Low
### Assumption 2: [Another assumption]
[... repeat structure ...]
## Blockers Identified
- [Blocker 1]: [Description and potential workaround]
- [Blocker 2]: [Description and potential workaround]
Phase 3: Example Discovery
## Similar Implementations
### Example 1: [Description]
**Location**: file.ts:123-145
**Pattern**: [What pattern it uses]
**Applicable**: ✓ Yes / ✗ No / ⚠ Partially
### Example 2: [Description]
[... repeat structure ...]
Research Strategies
Strategy 1: Codebase Pattern Search
Use search-strategies skill for optimal search:
1. Glob for candidate files: "**/*auth*"
2. Grep for specific pattern: "async fn login"
3. Read implementation: auth.rs:45-120
4. Extract pattern
Strategy 2: Documentation Verification
1. Read package.json / Cargo.toml / requirements.txt
2. Check version compatibility
3. Read docs for API changes
4. Verify example code still works
Strategy 3: External API Check
1. Read API documentation
2. Check rate limits
3. Verify authentication method
4. Test with sample call (if safe)
Output Structure
# Research Report: [Feature/Task Name]
## Verification Summary
- **Packages**: X/Y verified, Z missing
- **APIs**: X/Y available, Z deprecated
- **Examples**: Found X similar implementations
- **Blockers**: X identified, Y resolved, Z remaining
## Detailed Findings
### Dependency Status
[See Phase 1 above]
### Technical Feasibility
[See Phase 2 above]
### Code Examples
[See Phase 3 above]
## Recommendations
### ✅ Proceed with Original Plan
[If all assumptions verified]
### ⚠ Modify Approach
**Changes needed**:
1. [Modification 1]
2. [Modification 2]
**Reason**: [Why original won't work]
### ✗ Blocked / Requires Discussion
**Blockers**:
1. [Critical blocker]
**Options**:
1. [Alternative 1]
2. [Alternative 2]
## Next Steps
**If verified**: Transition to ACTION mode (implementation)
**If blocked**: Escalate to user or revise approach in DELIBERATION
Integration
- Auto-load:
search-strategiesskill (optimal search patterns) - Auto-load:
codebase-locatoragent (if open-ended search needed) - Use: Read, Grep, Glob tools
Best Practices
✅ DO:
- Be systematic in verification
- Document what you checked
- Note version numbers
- Find concrete examples
- Identify blockers early
- Stay focused (5-20 calls max)
❌ DON'T:
- Start implementing
- Make hundreds of tool calls
- Assume without checking
- Skip version verification
- Ignore deprecation warnings
Action Policy
<default_behavior> This command analyzes and recommends without making changes. Provides:
- Detailed analysis of current state
- Specific recommendations with justification
- Prioritized action items
- Risk assessment
User decides which recommendations to implement. </default_behavior>
Success Output
When research completes successfully:
✅ COMMAND COMPLETE: /research
Topic: <research topic>
Packages: X/Y verified
APIs: M available
Blockers: N identified
Recommendation: <proceed|modify|blocked>
Completion Checklist
Before marking complete:
- Dependencies verified
- APIs checked
- Examples found
- Blockers documented
- Recommendation provided
Failure Indicators
This command has FAILED if:
- ❌ No verification performed
- ❌ Started implementing (research only!)
- ❌ No recommendation given
- ❌ Exceeded tool call limit (5-20)
When NOT to Use
Do NOT use when:
- Ready to implement (use /implement)
- Need to fix code (use /debug)
- Simple known task (skip research)
Anti-Patterns (Avoid)
| Anti-Pattern | Problem | Solution |
|---|---|---|
| Start coding | Research only | Stay in verification mode |
| Too many calls | Context waste | Limit to 5-20 calls |
| Skip version check | Incompatibility | Always check versions |
Principles
This command embodies:
- #10 Research When in Doubt - Verify before acting
- #5 No Assumptions - Check everything
- #9 Based on Facts - Evidence-based decisions
Full Standard: CODITECT-STANDARD-AUTOMATION.md