research

## User Input

```text
$ARGUMENTS
```

You **MUST** parse the user input to extract the feature slug (the folder name in `rpi/`).

**Expected Input Format**: `rpi/{feature-slug}/REQUEST.md`

## Purpose

This command performs comprehensive research and analysis of feature requests **before** the planning phase begins. It acts as a critical GO/NO-GO gate to determine whether a feature idea should proceed to detailed planning.

**Key Objectives**:
- Assess product-market fit and user value
- Evaluate technical feasibility and complexity
- Identify risks and potential blockers
- Determine the right approach (build, buy, partner, or decline)
- Make go/no-go recommendation with clear rationale

**Prerequisites**:
- Feature folder exists at `rpi/{feature-slug}/`
- Feature request file exists at `rpi/{feature-slug}/REQUEST.md`

**Output Location**: `rpi/{feature-slug}/research/RESEARCH.md`

**This is Step 2 of the RPI Workflow** (after initial feature description in Step 1).

## Outline

1. **Load Context**: Read feature description from `rpi/{feature-slug}/` and project constitution (if exists)
2. **Parse Feature Request**: Use requirement-parser agent to extract structured requirements
3. **Execute Multi-Phase Research**:
   - Phase 1: Parse Feature Request (requirement-parser agent)
   - Phase 2: Product Analysis with Constitution Alignment (product-manager agent)
   - Phase 2.5: Technical Discovery (Explore agent) - **CRITICAL: Deep code exploration**
   - Phase 3: Technical Feasibility (senior-software-engineer agent)
   - Phase 4: Strategic Assessment (technical-cto-advisor agent)
   - Phase 5: Generate Research Report (documentation-analyst-writer agent)
4. **Synthesize Recommendation**: Combine all analyses into clear go/no-go recommendation
5. **Validate Output**: Check against quality gates
6. **Report Completion**: Provide recommendation, next steps, and report location

## Phases

### Phase 0: Load Context

**Prerequisites**: Feature slug provided, `rpi/{feature-slug}/REQUEST.md` exists

**Process**:
1. **Read feature description**:
   - Read `rpi/{feature-slug}/REQUEST.md` (required)
   - Extract feature requirements and goals from REQUEST.md

2. **Check for project constitution** (optional):
   - Look for a constitution or principles document in the repository
   - Common locations: `constitution.md`, `PRINCIPLES.md`, `.project/constitution.md`
   - If found, extract core principles, constraints, and objectives

3. **Create research context**:
   - Synthesize into concise summary for agents
   - Identify key alignment criteria

**Outputs**:
- Feature description summary
- Constitutional principles (if found)
- Alignment criteria for evaluation

**Validation**:
- [ ] Feature folder exists in `rpi/{feature-slug}/`
- [ ] Feature description extracted
- [ ] Constitution checked and loaded (if exists)

---

### Phase 1: Parse Feature Request

**Prerequisites**: Phase 0 complete

**Agent**: requirement-parser (planning domain)

**Process**:
1. **Launch requirement-parser agent** with feature description
2. **Agent extracts**:
   - Feature name and type
   - Target component(s)
   - Goals and objectives
   - Functional and non-functional requirements
   - Constraints and assumptions
   - Complexity estimate
   - Clarifying questions (if any)

3. **Review parsing results**:
   - If clarifying questions exist, **STOP and ask user** before proceeding

**Outputs**:
- Structured requirements document
- Feature metadata (name, type, component, complexity)
- Clarifying questions (if any)

---

### Phase 2: Product Analysis with Constitution Alignment

**Prerequisites**: Phase 1 complete, requirements clear

**Agent**: product-manager

**Process**:
1. **Launch product-manager agent** with:
   - Parsed requirements from Phase 1
   - Constitutional context from Phase 0

2. **Agent analyzes**:
   - **User Value**: Who benefits? How much impact?
   - **Market Fit**: Does this align with market needs?
   - **Product Vision**: Does this fit our product strategy?
   - **Constitutional Alignment**: Does this align with project principles?
   - **Constraints Check**: Does this violate any constitutional constraints?

3. **Agent provides**:
   - Product viability score (High/Medium/Low)
   - User value assessment
   - Strategic alignment evaluation
   - Priority recommendation
   - Product concerns or red flags

**Outputs**:
- Product viability assessment
- User value analysis
- Strategic alignment score
- Constitutional alignment summary (if applicable)

---

### Phase 2.5: Technical Discovery (Code Exploration)

**Prerequisites**: Phases 1-2 complete, product viability established

**Agent**: Explore (via Task tool with subagent_type="Explore")

**Purpose**: **CRITICAL PHASE** - Deeply analyze existing codebase BEFORE making technical feasibility assessment.

**Process**:
1. **Launch Explore agent** with target component(s)
2. **Agent investigates**:
   - **Existing Implementation**: What code already exists for similar functionality?
   - **Integration Points**: What systems/modules would this feature touch?
   - **Current Architecture**: How is the current system structured?
   - **Data Models**: What database schemas or data structures exist?
   - **Dependencies**: What libraries, services are already integrated?
   - **Existing Patterns**: What coding patterns and conventions are used?

3. **Agent provides**:
   - **Current State Summary**: What exists today
   - **Integration Analysis**: Where proposed feature would fit
   - **Code Conflicts**: What would break or conflict
   - **Leverage Opportunities**: What can be reused vs rebuilt
   - **Technical Constraints**: Real constraints from existing code

**Outputs**:
- Current implementation summary
- Integration points map
- Code conflicts identified
- Reusable components identified
- Technical constraints from code

**Critical**: This phase ensures Phase 3 is based on **actual code reality**, not assumptions.

---

### Phase 3: Technical Feasibilit