home / skills / ratacat / claude-skills / technical-planning

technical-planning skill

/skills/technical-planning

This skill helps plan technical projects with risk-first development, milestone structuring, and explicit deferral to maximize clarity and progress.

npx playbooks add skill ratacat/claude-skills --skill technical-planning

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
11.0 KB
---
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

Overview

This skill plans technical projects using a risk-first development approach, milestone structuring, and explicit managed deferral. I designed it to help teams define outcome-focused milestones, prioritize high-impact unknowns, and defer noncritical decisions until the last responsible moment. It emphasizes measurable success criteria and continuous validation.

How this skill works

The skill inspects project requirements and identifies technical risks, then produces a four-phase planning framework: Requirements & Risk Analysis, Milestone Planning, Implementation Strategy, and Execution Framework. It recommends sequencing milestones to resolve critical unknowns first, creating working proofs-of-concept, and documenting deferred items with target milestones. The output includes milestone goals, core tasks (outcome-focused), success criteria, risk mitigations, and a deferral registry.

When to use it

  • Planning a new software project or greenfield architecture
  • Defining milestones and delivery cycles for complex features
  • Breaking down a large initiative into manageable, testable iterations
  • Prioritizing work when technical feasibility is uncertain
  • Aligning teams on what to defer vs. what to prove early

Best practices

  • Focus task definitions on outcomes and constraints, not implementation steps
  • Address highest-impact unknowns in Milestone 1 with proofs-of-concept
  • Document deferred items, reasons, and target milestones for review
  • Reserve 20–30% of sprint time for exploration and learning
  • Measure success with predefined metrics and continuous validation

Example use cases

  • Create a milestone plan that validates an external API integration before full implementation
  • Structure a 12-week project into three 4-week cycles that each deliver working functionality
  • Prioritize addressing performance bottlenecks with an early benchmark and prototype
  • Plan feature rollouts where UI polish and optimizations are deferred until after user validation
  • Onboard a team by defining clear success criteria and a risk register for initial milestones

FAQ

What decisions should I make early versus defer?

Decide early on user problems, success metrics, hard constraints, and critical integrations; defer algorithm, code organization, library choices, and polish until implementation reveals the best options.

How do I track deferred items?

Maintain a deferral registry listing each item, rationale, category (debt/polish/edge case), and the target milestone for re-evaluation or completion.

How long should milestones be?

Use 4–8 week cycles based on project complexity; ensure each milestone delivers testable, working functionality and resolves at least one high-risk unknown.