---
name: technical-planning
description: Plans technical projects with risk-first development, milestone structuring, and managed deferral. Use when planning software projects, defining milestones, structuring development phases, or breaking down complex tasks into manageable iterations.
---

# Technical Planning

## Core Principles

**Focus on "What" Not "How"**: Define deliverable outcomes, not implementation details. Specify constraints and success criteria, but leave implementation choices flexible.

**Last Responsible Moment**: Defer decisions until you have enough information to make them well, but not so late that they block progress. Make reversible decisions quickly; delay irreversible ones until necessary.

**Risk-First Development**: Address highest-risk technical challenges first. Build proof-of-concepts before full implementation. Ship working but imperfect solutions to validate core assumptions early.

**Managed Deferral**: Explicitly document what's being deferred and when it will be addressed. Distinguish between core value delivery and polish/optimization.

### Progress Tracking with TodoWrite

Use TodoWrite to track planning progress through the four phases:

1. **At start**: Create todos for each phase:
   ```
   ☐ Phase 1: Requirements & Risk Analysis
   ☐ Phase 2: Milestone Planning
   ☐ Phase 3: Implementation Strategy
   ☐ Phase 4: Execution Framework
   ```

2. **During planning**: Mark phases in_progress → completed as you work through them. Add sub-todos for key deliverables:
   ```
   ☐ Extract core requirements (2-3 user journeys)
   ☐ Identify technical risks (high/integration/performance/architecture)
   ☐ Define milestones with success criteria
   ☐ Document deferred items with rationale
   ```

3. **For complex projects**: Track clarifying questions and their resolutions as todos - prevents proceeding with incomplete information

### Decision Timing Framework

**Decide Early (Requirements Phase)**:
- User problems being solved
- Success criteria and measurement
- Hard constraints (security, compliance, performance SLAs)
- Critical integrations and dependencies
- Technology choices that affect architecture

**Defer to Implementation (Execution Phase)**:
- Specific algorithms or data structures
- Internal API design details
- Code organization patterns
- Library choices (when multiple options work)
- Performance optimizations (until proven necessary)
- UI/UX details (until user testing)

**Why**: Early decisions should enable work without locking in details. Implementation decisions become clearer with hands-on experience and often reveal better alternatives than upfront planning suggests.

## Agent Guidelines

**Seek Clarity Before Proceeding**: Never assume unclear requirements, technical constraints, or business priorities. Only proceed when you have 80%+ confidence on critical aspects. Ask specific questions about:

- User problems being solved (not just features requested)
- Success criteria and measurement approaches
- Technical constraints and existing system dependencies
- Team capabilities and technology preferences
- Timeline constraints and priority trade-offs
- Performance and scalability requirements

## Phase 1: Requirements & Risk Analysis

### Prerequisites Check

Verify:

- What user problems are being solved?
- Who are the primary users and their workflows?
- How will success be measured?
- What are the technical and business constraints?

### Extract Core Requirements

1. Identify fundamental user problems being solved
2. Map primary user journeys (focus on 2-3 critical paths)
3. Define project success metrics

### Identify Technical Risks

1. **High-Impact Risks**: Technical unknowns that could invalidate the approach
2. **Integration Risks**: External system dependencies and compatibility concerns
3. **Performance Risks**: Scalability bottlenecks and algorithmic challenges
4. **Architecture Risks**: Fundamental design decisions with broad implications

### Risk Prioritization Matrix

- **Critical + Unknown**: Must be addressed in Milestone 1 with proof-of-concepts
- **Critical + Known**: Address in early milestones with established patterns
- **Non-Critical**: Defer to later milestones or eliminate

## Phase 2: Milestone Planning

### Prerequisites Check

Verify:

- Priority order of technical risks identified in Phase 1
- Team capacity and available timeline
- Dependencies between different components
- Definition of "working functionality" for this project

### Milestone Structure

- **Timeline**: 4-8 week cycles based on project complexity
- **Deliverable**: Each milestone must produce working, testable functionality
- **Risk Focus**: Sequence milestones to tackle highest-risk items first

### For Each Milestone, Define:

**Goal**: One-sentence description of milestone outcome

**Core Tasks**: 4-6 main implementation tasks following Last Responsible Moment principle:
- Define clear outcomes and constraints
- Identify dependencies and integration points
- Provide context and considerations (not step-by-step instructions)
- Leave implementation details flexible
- Flag questions to resolve during execution

**Success Criteria**:
- Minimum Viable Success (must achieve for milestone completion)
- Complete Success (ideal outcome including polish)

**Risk Mitigation**: Specific unknowns to be resolved in this milestone

**Deferred Items**: What's intentionally left out and target milestone for inclusion

### Task Breakdown Guidelines

When breaking down tasks, provide **guidance not prescription**:

**✓ Good Task Definition** (outcome-focused):
- Goal: "Enable users to authenticate securely"
- Constraints: "Must integrate with existing session middleware; <100ms response time"
- Guidance: "Consider session vs. token auth; review existing patterns in src/middleware/"
- Validation: "Users can log in, sessions persist, tests pass"

**✗ Poor Task Definition** (overly prescriptive):
- Step 1: "Create file auth.js with bcrypt import"
- Step 2: "Write hashPassword function using bcrypt.hash with 10 rounds"
- Step 3: "Create Express middleware checking req.session.userId"

**Why**: Good definitions let the implementer choose the best approach based on what they learn. Poor definitions lock in choices before understanding the context, often leading to rework.

### Example Milestone Definition

**Goal**: Validate user authentication and basic data retrieval from external API

**Core Tasks**:
1. Implement OAuth flow with provider
2. Create user session management
3. Build API client with error handling
4. Add basic user profile display

**Success Criteria**:
- Minimum: Users can log in and see their profile data
- Complete: Include profile editing and session persistence

**Risk Mitigation**: Confirm API rate limits and response time under load

**Deferred**: Advanced profile features, password reset flow (Milestone 3)

## Phase 3: Implementation Strategy

### Development Approach

- **Prototype First**: Build throwaway versions to test risky assumptions
- **Core Before Polish**: Implement functional features before UI refinements
- **Integration Early**: Test external system connections in first milestone
- **Measure Continuously**: Track performance and user metrics from day one

### Technology Selection Criteria

1. **Team Expertise**: Prefer technologies your team knows well
2. **Proven Reliability**: Choose mature, battle-tested options for core systems
3. **Integration Capability**: Ensure compatibility with existing tools/systems
4. **Scalability Path**: Technology should support anticipated growth

### Quality Gates

- All code must have basic test coverage
- Performance benchmarks must be met for core user journeys
- Security review required for authentication and data handling
- Accessibility standards met for user-facing features

## Phase 4: Execution Framework

### Sprint Planning

1. **Risk Assessment**: Identify unknowns in upcoming work
2. **Exploration Time**: Reserve 20-30% of sprint for prototyping/learning
3. **Definition of Done**: Must include working functionality, not just completed code
4. **Continuous Validation**: Regular stakeholder feedback on core user journeys

### Deferral Management

- **Regular Review**: Evaluate deferred items each milestone for continued relevance
- **Categories**: Technical debt, UX polish, edge cases, performance optimization, advanced features
- **Scheduling**: Plan deferred items into appropriate future milestones
- **Elimination**: Some deferred items may become unnecessary

### Documentation Requirements

- Technical specification focusing on deliverable outcomes
- Risk register with mitigation plans
- Deferred items registry with target scheduling
- Architecture decision records for major choices

## Decision Framework for Agents

**IF** project has unknown technical feasibility → Schedule proof-of-concept in Milestone 1
**IF** project requires external integrations → Test minimal integration in first milestone
**IF** project has performance requirements → Establish benchmarks and test core algorithms early
**IF** team lacks expertise in chosen technology → Include learning/exploration time in early milestones
**IF** project has tight deadlines → Focus on minimum viable success criteria and defer polish
**IF** project is greenfield → Spend extra time on architecture decisions and foundational setup
**IF** project is enhancement → Focus on integration points and backward compatibility

### When Unclear - Ask These Questions

**WHEN** requirements are vague → "What specific user problem does this solve? How will we measure success?"
**WHEN** technical scope is undefined → "What are the must-have vs. nice-to-have technical capabilities?"
**WHEN** timeline is unrealistic → "What are the non-negotiable deadlines and what flexibility exists?"
**WHEN** team capabilities are unknown → "What technologies does the team have experience with? What are the skill gaps?"
**WHEN** integration points are unclear → "What existing systems must this connect to? What are the data formats and API constraints?"
**WHEN** performance needs are unspecified → "What are the expected user loads and response time requirements?"
**WHEN** success criteria are missing → "How will we know this milestone is complete and successful?"

## Common Pitfalls to Avoid

- **Making assumptions instead of asking clarifying questions** when requirements are unclear
- **Proceeding with incomplete information** rather than requesting necessary details
- **Creating overly prescriptive task definitions** with step-by-step instructions instead of outcome-focused guidance
- **Making implementation decisions too early** when they could be deferred to execution
- Spending time on low-risk features while deferring critical unknowns
- Over-engineering solutions before validating core assumptions
- Planning implementation details instead of focusing on deliverable outcomes
- **Guessing at user needs** instead of understanding specific problems being solved
- Failing to document deferral decisions and rationale
- Optimizing prematurely instead of proving core functionality first
- **Locking in technology choices** before understanding the full context