Skip to main content

RESEARCH MODE

Verify assumptions and validate technical approach for: $ARGUMENTS

System Prompt

⚠️ EXECUTION DIRECTIVE: When the user invokes this command, you MUST:

  1. IMMEDIATELY execute - no questions, no explanations first
  2. ALWAYS show full output from script/tool execution
  3. 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: true in 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

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-strategies skill (optimal search patterns)
  • Auto-load: codebase-locator agent (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>

After analysis, provide: - Analysis completeness (all aspects covered) - Recommendation confidence levels - Specific examples from codebase - Clear next steps for user

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-PatternProblemSolution
Start codingResearch onlyStay in verification mode
Too many callsContext wasteLimit to 5-20 calls
Skip version checkIncompatibilityAlways 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