plan

## User Input

```text
$ARGUMENTS
```

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

## Purpose

This command creates comprehensive planning documentation for a feature request. It generates detailed specifications, technical design, and implementation plans in the feature's RPI folder.

**Prerequisites**:
- Feature folder exists at `rpi/{feature-slug}/`
- Research completed with GO recommendation (`rpi/{feature-slug}/research/RESEARCH.md` exists)

**Output Location**: All files saved to `rpi/{feature-slug}/plan/`

**This is Step 3 of the RPI Workflow** (after Research approves with GO).

## Outline

1. **Load Context**: Read research report and project constitution (if exists)
2. **Understand Requirements**: Parse feature scope and requirements
3. **Analyze Technical Requirements**: Review architecture and dependencies
4. **Design Architecture**: Create high-level architecture and API contracts
5. **Break Down Implementation**: Create phased task breakdown
6. **Generate Documentation**: Create structured documentation files
7. **Validate Output**: Ensure all quality gates pass
8. **Report Completion**: Provide summary and next steps

## Phases

### Phase 0: Load Context

**Prerequisites**: Feature slug provided

**Process**:
1. **Verify research completed**:
   - Check `rpi/{feature-slug}/research/RESEARCH.md` exists
   - Verify GO recommendation (warn if NO-GO or CONDITIONAL)

2. **Read research findings**:
   - Extract product analysis
   - Extract technical discovery
   - Extract technical feasibility assessment
   - Note risks and constraints

3. **Load project constitution** (if exists):
   - Look for a constitution or principles document in the repository
   - Extract relevant constraints and preferences

**Outputs**:
- Research summary
- Constitutional context (if found)
- Planning constraints

**Validation**:
- [ ] Research report exists
- [ ] GO recommendation confirmed
- [ ] Constitution loaded (if exists)

---

### Phase 1: Understand Feature Requirements

**Prerequisites**: Phase 0 complete

**Process**:
1. **Parse Feature Description** from research report:
   - Extract feature name and primary goal
   - Identify target component(s)
   - Understand user-facing vs. technical feature
   - Determine feature complexity level

2. **Identify Affected Components**:
   - Primary component (where feature lives)
   - Secondary components (integration points)
   - Shared utilities needed
   - External dependencies

3. **Research Existing Patterns**:
   - Search for similar features in codebase
   - Review component architecture and patterns
   - Identify reusable code and patterns

**Outputs**:
- Feature scope document (internal)
- Affected components list
- Existing patterns catalog

**Validation**:
- [ ] Feature name and goal clearly defined
- [ ] Target component(s) identified
- [ ] Feature complexity assessed

---

### Phase 2: Analyze Technical Requirements

**Prerequisites**: Phase 1 complete

**Process**:
1. **Review Component Architecture**:
   - Read component README and documentation
   - Review existing code structure
   - Identify architectural patterns used

2. **Identify Technical Dependencies**:
   - Internal dependencies (other components, shared utilities)
   - External dependencies (APIs, services, libraries)
   - Database/storage requirements
   - Authentication/authorization needs

3. **Assess Integration Points**:
   - APIs that need to be created or modified
   - Database schema changes required
   - Event/message flows
   - Frontend-backend integration

4. **Evaluate Technical Risks**:
   - Breaking changes to existing features
   - Performance implications
   - Security concerns
   - Data migration needs

**Outputs**:
- Technical requirements document (internal)
- Dependency map
- Integration point diagram
- Risk assessment

**Validation**:
- [ ] Component architecture understood
- [ ] All dependencies identified
- [ ] Integration points mapped
- [ ] Technical risks assessed

---

### Phase 3: Design Feature Architecture

**Prerequisites**: Phases 1-2 complete

**Agent**: senior-software-engineer

**Process**:
1. **Design High-Level Architecture**:
   - Component/module structure
   - Data flow diagrams
   - API interfaces
   - Database schema changes

2. **Define Implementation Approach**:
   - File structure and organization
   - Code organization patterns
   - Testing strategy
   - Error handling approach

3. **Plan Database/Storage Changes** (if applicable):
   - New collections/tables
   - Schema modifications
   - Migration strategy
   - Data validation rules

4. **Design API Contracts** (if applicable):
   - Request/response formats
   - Authentication requirements
   - Error responses

5. **Plan Testing Strategy**:
   - Unit test requirements
   - Integration test scenarios
   - End-to-end test cases

**Outputs**:
- Architecture design document (internal)
- API specifications
- Database schema design
- Testing strategy

**Validation**:
- [ ] High-level architecture designed
- [ ] Implementation approach defined
- [ ] Database changes planned (if needed)
- [ ] API contracts specified (if needed)
- [ ] Testing strategy complete

---

### Phase 4: Break Down Implementation Tasks

**Prerequisites**: Phases 1-3 complete

**Process**:
1. **Identify Implementation Phases**:
   - Break feature into 3-5 logical phases
   - Each phase should deliver working, testable functionality
   - Phases should build on each other progressively

2. **Create Task Breakdown for Each Phase**:
   - List specific implementation tasks
   - Estimate complexity (Low/Medium/High)
   - Identify task dependencies
   - Assign to appropriate code areas

3. **Define Success Criteria**:
   - Acceptance criteria for each phase
   - Testing requirements
   - Documentation requirements

4. **Identify Parallelization Opportunities**:
   - Tasks that can be done concurrently
   - Frontend/backend parallel work
   - Independent module development

*