Create Implementation Plan

Complex features require detailed plans outlining technical approach, task breakdown, and dependencies before implementation begins. This skill analyzes requirements to generate structured implementation plans covering architecture decisions, development phases, resource needs, and risk mitigation, ensuring teams understand full scope before writing code.

What Is This?

Overview

Create Implementation Plan transforms feature specifications into actionable development plans. It identifies technical requirements and constraints, proposes architecture and design approach, breaks work into development phases, estimates complexity and effort, highlights dependencies and risks, suggests team composition needs, and outlines testing and deployment strategy.

The skill bridges product requirements and engineering execution, translating user needs into technical tasks, surfacing hidden complexity, and creating a roadmap for orderly implementation that prevents surprises mid-development.

Who Should Use This

Technical leads planning features. Engineering managers allocating resources. Software architects designing systems. Product managers understanding effort. Development teams estimating work. Solo developers organizing large tasks.

Why Use It?

Problems It Solves

Teams start implementation without complete understanding, causing mid-development surprises. Plans surface complexity upfront, enabling informed decisions before committing.

Dependencies between components remain unclear until conflicts arise. Explicit dependency mapping prevents parallel work from blocking unexpectedly.

Resource needs are underestimated, leading to timeline misses. Plans identify team composition and skill requirements early.

Technical risks emerge late, causing delays. Upfront risk analysis enables mitigation planning before issues impact delivery.

Core Highlights

Technical requirement extraction. Architecture approach recommendation. Phase-based task breakdown. Dependency identification. Risk analysis and mitigation. Team composition suggestions. Effort estimation guidance. Testing strategy planning. Deployment approach definition.

How to Use It?

Basic Usage

Provide a feature specification or requirements document. The skill generates a comprehensive implementation plan with technical approach, phases, and considerations.

Create implementation plan for multi-tenant data isolation feature

Generate plan for migrating authentication from sessions to JWT tokens

Specific Scenarios

For new features, emphasize architecture decisions.

Plan implementation for real-time collaboration covering WebSocket architecture and state sync

For migrations, highlight transition strategy.

Create plan for database migration from MySQL to PostgreSQL with zero downtime

For refactoring, focus on risk mitigation.

Plan refactoring legacy payment code with backward compatibility preservation

Real World Examples

A product manager requests a search feature supporting filters, sorting, and pagination. The engineering team needs an implementation plan before committing to a timeline. Requirements are analyzed identifying full-text search, faceted filtering, and performance needs. The plan proposes Elasticsearch integration versus database search with tradeoffs, breaks implementation into phases covering basic search, filter implementation, and performance optimization, identifies dependencies on database schema and API changes, estimates two-sprint effort, highlights risks around search relevance tuning, suggests a backend developer plus DevOps for Elasticsearch deployment, and outlines a testing strategy including performance benchmarks.

A technical lead plans a microservices migration for a monolithic application. The generated plan identifies services to extract based on bounded contexts, proposes the strangler fig pattern for gradual migration, phases work starting with read-only services, documents inter-service communication using events, estimates a six-month timeline, highlights risks of data consistency and deployment complexity, suggests a three-person team with microservices experience, and outlines contract testing. Leadership approves the plan with full understanding of the commitment.

A developer implementing a complex reporting feature uses the skill to clarify approach before coding. The plan proposes background job processing to avoid request timeouts, identifies data sources and required transformations, breaks work into job scheduler, data fetchers, aggregation logic, and report formatter, estimates two weeks, notes third-party API rate limit risks, suggests a caching strategy, and defines a testing approach with sample data.

Advanced Tips

Review plans with stakeholders before implementation. Update plans as understanding evolves. Include architecture diagrams for clarity. Document decision rationale for future reference. Break large plans into smaller reviewable sections. Consider alternative approaches explicitly. Link to architectural decision records.

When to Use It?

Use Cases

Feature development planning. System architecture design. Migration strategy development. Refactoring scope definition. Technical spike planning. Resource allocation decisions. Timeline estimation. Risk assessment for complex work.

Related Topics

Software architecture design. Project planning techniques. Technical estimation methods. Risk management practices. Agile planning approaches. Software design documentation. Team resource planning.

Important Notes

Requirements

Clear feature requirements or goals. Understanding of existing system architecture. Context about team skills and capacity. Knowledge of technical constraints. Awareness of timeline expectations.

Usage Recommendations

Create plans before implementation begins. Review with the team for validation. Update as understanding improves. Document assumptions explicitly. Identify areas needing research. Balance detail with readability. Link to requirements and specifications. Use plans for stakeholder communication.

Limitations

Plans require technical expertise to validate. Cannot predict all implementation challenges. Estimates are approximate, not commitments. Quality depends on requirement clarity. Plans should be living documents requiring regular updates.