Develop

---
description: Analyze Linear issue and create comprehensive development plan
argument-hint: "[SPI-xxx]"
allowed-tools: mcp__linear-server__get_issue, mcp__linear-server__update_issue, mcp__linear-server__create_comment, Grep, Read, Glob
model: opus
---

# /develop - Development Manager Workflow

This command implements the Development Manager workflow for analyzing Linear issues and creating comprehensive development plans. It's the centerpiece of our development workflow automation.

## What This Command Does

When you run `/develop SPI-xxx`, Claude will:

1. Fetch the complete Linear issue hierarchy (subtask → story → epic)
2. Search and analyze relevant project documentation
3. Perform deep analysis of scope, complexity, and technical approach
4. Determine agent delegation strategy with think levels
5. Ask clarifying questions if needed
6. Post the development plan to Linear as a comment
7. Transition the issue to "In Progress"
8. Present a comprehensive development plan with next steps

## Workflow Instructions

Follow these steps in order using ULTRATHINK analysis mode. Be thorough but respect YAGNI principles.

### Step 1: Fetch Linear Issue Hierarchy

**Objective**: Build complete context from the issue and all its parents.

**Actions**:
1. Use `mcp__linear-server__get_issue` to fetch the issue `$1` (the Linear issue ID argument)
2. Examine the response for the `parentId` field
3. If a parent exists, recursively fetch it:
   - Subtask → fetch parent Story
   - Story → fetch parent Epic
   - Continue until reaching top-level Epic or no more parents
4. Build a complete hierarchy map showing relationships

**Important**:
- Handle cases where issues have no parents gracefully
- Handle issues that are already top-level epics
- Be defensive against circular references (shouldn't happen, but check)
- Store parent issue descriptions for context

**Example Output Structure**:

Epic: [SPI-1132] Core Provider Implementation └─ Story: [SPI-1140] Implement SSH Integration └─ Subtask: [SPI-1146] Create SSH Info Action ← This Issue

### Step 2: Search Related Documentation

**Objective**: Find and analyze relevant project documentation to inform the plan.

**Actions**:
1. Search `docs/` directory for relevant documentation:
   - Always check: `docs/reference/PRD.md` (product requirements)
   - Always check: `docs/architecture/overview.md` (technical architecture)
   - Search for domain-specific docs based on issue keywords
2. Use `Grep` to search for:
   - Feature names mentioned in the issue
   - Technical terms from issue description
   - Component names (e.g., "MCP", "Workflow", "Session", "Repository")
   - Related class or module names
   - Domain keywords (authentication, testing, deployment)
3. Use `Read` to review relevant sections of found documents
4. Build a knowledge base of:
   - Existing design decisions
   - Architecture constraints
   - Related features
   - Technical patterns to follow

**Search Strategy**:
- Start with exact phrase matches in file names
- Then search content with keywords
- Check both concepts/, patterns/, guides/, examples/, reference/
- Prioritize patterns and guides over examples

**Documentation Structure Reference**:
- **Concepts** (`docs/concepts/`) - Foundational knowledge
- **Patterns** (`docs/patterns/`) - Implementation approaches
- **Examples** (`docs/examples/`) - Working code samples
- **Guides** (`docs/guides/`) - Step-by-step procedures
- **Reference** (`docs/reference/`) - Quick lookups

**If No Documentation Found**:
- Note this in the analysis
- Flag that design documentation may need to be created
- Proceed with plan based on issue description and project conventions

### Step 3: Deep Analysis ("Ultrathink")

**Objective**: Comprehensively analyze the work to create an informed development plan.

**Perform Analysis On**:

#### Scope & Complexity
- What exactly needs to be built/changed?
- What is explicitly in scope?
- What is explicitly out of scope?
- How does this fit into the larger feature/epic?
- What is the estimated complexity? (Use Fibonacci: 1, 2, 3, 5, 8, 13, 21)
  - 1 point: Trivial - straightforward implementation
  - 2 points: Simple - well-understood requirements
  - 3 points: Moderate - some architectural decisions needed
  - 5 points: Moderately complex - multiple integrations
  - 8 points: Complex - substantial architectural work
  - 13 points: Very complex - major feature, consider decomposition
  - 21 points: Too large - needs breakdown

#### Technical Approach
- What is the high-level implementation strategy?
- Which existing components will be modified?
- Which new components need to be created?
- What are the key technical decisions needed?
- Are there multiple viable approaches? (compare if so)
- What patterns from existing code should be followed?
- What are the Kotlin/Ktor/DDD specific considerations?

#### YAGNI Assessment
**Critical**: Apply "You Ain't Gonna Need It" principles:
- Are we building only what's needed NOW?
- Are we avoiding over-engineering?
- Are we designing for current requirements, not hypothetical futures?
- Can we simplify the approach?
- What's the minimum viable implementation?
- Are we following the principle: "The simplest thing that could possibly work"?

#### Design Document Assessment
Determine if a technical design document is needed:

**Create Design Doc IF**:
- Architectural changes required
- New major components/systems
- Complex integrations
- Significant API changes
- Multiple implementation approaches to compare
- High technical risk

**Skip Design Doc IF**:
- Small feature additions
- Bug fixes
- Documentation updates
- Simple, straightforward implementations
- Well-established patterns being followed

#### Testing Requirements
- What test category: unit, integration, or system?
- What are the critical paths that must be tested?
- Unit tests needed? (business logic, domain models)
- Integration tests needed? (database, infrastructure)
- System tests needed?