Implementation Planning

Transform TASKS.md and ARCHITECTURE.md artifacts into a comprehensive IMPLEMENTATION_PLAN.md artifact containing phase definitions, sprint breakdowns, critical path analysis, risk assessment with mitigations, and a definition of done. This is the sixth step in the greenfield specification pipeline — it takes a granular task list and produces a time-sequenced execution plan that can be tracked and managed.

When to Use This Skill

• TASKS.md and ARCHITECTURE.md exist and have been validated
• The team needs a phased rollout strategy
• Sprint assignments need to be made based on dependencies and priorities
• Project risks need to be formally assessed and mitigated
• Stakeholders need delivery milestones and timelines
• A definition of done needs to be established for quality gates

Pipeline Position

[Raw Idea] → [PROBLEM_BRIEF.md] → [REQUIREMENTS.md] → [FUNCTIONAL_SPEC.md] → [ARCHITECTURE.md] → [TASKS.md] → **IMPLEMENTATION PLANNING** → [IMPLEMENTATION_PLAN.md]

Input: artifacts/greenfield/<project_name>/TASKS.md, artifacts/greenfield/<project_name>/ARCHITECTURE.md Output: artifacts/greenfield/<project_name>/IMPLEMENTATION_PLAN.md

Process

Step 1: Read and Analyze Inputs

Load TASKS.md and ARCHITECTURE.md. Extract:

From TASKS.md:

• Epic list (EPIC-NNNN) with priorities and effort estimates
• Task list (TASK-NNNN) with dependencies, types, and effort sizes
• Dependency graph and critical path
• Effort totals and parallelization opportunities
• Task type distribution (Feature, Chore, Test, Spike)

From ARCHITECTURE.md:

• Component catalog (COMP-NNNN) — determines integration milestones
• Technology stack — informs risk assessment
• Deployment architecture — determines release strategy
• Security architecture — determines compliance milestones
• Scalability notes — determines performance testing phases

Step 2: Define Project Phases

Group epics into phases based on priority and dependency order:

Standard phase structure:

Phase	Name	Focus	Exit Criteria
0	Foundation	Project setup, CI/CD, database, auth	Infrastructure operational, deploy pipeline green
1	Core MVP	P0 features end-to-end	All P0 acceptance criteria pass
2	Enhancement	P1 features, polish, performance	P1 features deployed, NFR metrics met
3	Optimization	P2 features, scale testing, hardening	Production-ready, all NFRs validated

Phase rules:

• Phase 0 always exists (foundation/infrastructure)
• P0 features must be in Phase 1
• P1 features in Phase 2
• P2 features in Phase 3 (or backlog)
• Each phase has clear exit criteria that are objectively verifiable
• Dependencies between epics must not cross phase boundaries downward (Phase 2 epic cannot depend on Phase 3 epic)
• Each phase should contain 2-4 sprints

Phase assignment process:

1. Place all infrastructure epics in Phase 0
2. Place all P0 epics in Phase 1 (sorted by dependency order)
3. Place P1 epics in Phase 2
4. Place P2 epics in Phase 3
5. Validate: no epic depends on a later-phase epic
6. If dependency violation exists, promote the dependency to an earlier phase

Step 3: Define Sprint Breakdown

Assign tasks to sprints within each phase:

Sprint parameters:

• Sprint duration: 2 weeks (default, adjustable)
• Sprint velocity: [total effort points available per sprint]
• Sprint capacity: velocity * (1 - buffer%), where buffer = 20% for interrupts/bugs

Sprint assignment algorithm:

1. Start with critical path tasks — these must be in the earliest possible sprint
2. Fill remaining capacity with non-critical tasks from the same phase
3. Respect all dependencies (a task cannot be in a sprint before its dependencies)
4. Balance effort types across sprints (avoid test-only or chore-only sprints)
5. Include buffer for bug fixes and scope clarification (20% of capacity)

Sprint format:

Sprint [N]: [Sprint Name/Theme]
Phase: [Phase Number]
Duration: [Start Week - End Week]
Capacity: [N] points (after buffer)
Planned Points: [N] points

Tasks:
  - TASK-NNNN: [Title] ([Size], [Points])
  - TASK-NNNN: [Title] ([Size], [Points])
  - ...

Sprint Goal: [One sentence describing what is achieved when all tasks complete]
Milestone: [Deliverable or demo-able increment]

Step 4: Identify Critical Path

Trace the longest dependency chain through the task graph:

Critical path analysis:

1. From the dependency graph in TASKS.md, identify all paths from root tasks to final tasks
2. Calculate the total effort (points) for each path
3. The path with the highest total effort is the critical path
4. Any delay on a critical path task delays the entire project
5. Tasks not on the critical path have "float" — they can be delayed without affecting the project end date

Create a Mermaid Gantt chart showing the critical path:

gantt
    title Implementation Timeline
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Phase 0: Foundation
    Project Setup        :crit, t1, 2026-03-01, 3d
    CI/CD Pipeline       :crit, t2, after t1, 2d
    Database Setup       :crit, t3, after t2, 2d

    section Phase 1: Core MVP
    User Auth            :crit, t4, after t3, 5d
    Core Feature A       :crit, t5, after t4, 8d
    Core Feature B       :t6, after t4, 5d
    Integration Tests    :crit, t7, after t5, 3d

    section Phase 2: Enhancement
    Feature C            :t8, after t7, 5d
    Performance Tuning   :t9, after t7, 3d

Critical path rules:

• Critical path tasks are highlighted (:crit in Mermaid)
• Non-critical tasks show their actual dependencies but are not highlighted
• Float is documented for non-critical tasks
• If the critical path changes during execution, the plan must be updated

Step 5: Assess Risks

Identify and assess project risks using a severity-based framework:

Risk format:

RISK-NNNN: [Risk Title]
Category: [Technical | Resource | External | Scope | Schedule | Quality]
Probability: [High | Medium | Low]
Impact: [High | Medium | Low]
Severity: P0 | P1 | P2
Description: [What could go wrong]
Affected Tasks: TASK-NNNN, TASK-NNNN
Mitigation Strategy: [How to reduce probability or impact]
Contingency Plan: [What to do if the risk materializes]
Owner: [Role responsible for monitoring this risk]
Trigger: [Observable indicator that the risk is materializing]

Severity matrix:

	Impact: High	Impact: Medium	Impact: Low
Probability: High	P0	P0	P1
Probability: Medium	P0	P1	P2
Probability: Low	P1	P2	P2

Risk sorting rule: RISK-NNNN IDs are assigned by sorting risks by severity first (P0 before P1 before P2), then alphabetically by risk title within each severity level.

Mandatory risk categories to assess:

1. Technical risks: Technology unknowns, integration complexity, performance uncertainty
2. Resource risks: Team availability, skill gaps, key person dependency
3. External risks: Third-party API changes, vendor reliability, regulatory changes
4. Scope risks: Requirement changes, feature creep, ambiguous specifications
5. Schedule risks: Underestimation, dependency delays, parallel work conflicts
6. Quality risks: Insufficient testing, technical debt, security vulnerabilities

Step 6: Define Definition of Done

Establish clear quality gates for different levels:

Task-level DoD:

• Code written and self-reviewed
• Unit tests written and passing
• Code review approved by at least one team member
• No new linting errors or warnings
• Acceptance criteria verified

Sprint-level DoD:

• All planned tasks meet task-level DoD
• Integration tests passing for completed features
• No critical bugs open from this sprint
• Sprint demo/review completed
• Documentation updated for completed features

Phase-level DoD:

• All sprint-level DoDs met for sprints in this phase
• Phase exit criteria verified
• End-to-end tests passing for all features in this phase
• Performance benchmarks met (per NFRs)
• Security review completed (for phases with auth/data features)
• Stakeholder sign-off obtained

Release DoD:

• All phase-level DoDs met
• Production deployment verified
• Monitoring and alerting operational
• Rollback procedure tested
• User documentation available
• Support team briefed

Output Format

Write the artifact following the template at ${CLAUDE_PLUGIN_ROOT}/reference/templates/IMPLEMENTATION_PLAN.template.md.

The artifact must follow the standard artifact template structure:

# IMPLEMENTATION_PLAN: [Project Name]

## Summary
[2-3 sentence summary: phase count, sprint count, total duration, critical path length, top risks]

## Inputs
- **Tasks**: `TASKS.md` — [EPIC count, TASK count, total effort points]
- **Architecture**: `ARCHITECTURE.md` — [deployment model, component count]

## Outputs
- This document (IMPLEMENTATION_PLAN.md)
- Final artifact in the greenfield pipeline

## Assumptions
- [ASM-0001]: [Planning assumption — e.g., "2-week sprints, team of 3 developers"]
- [ASM-0002]: [e.g., "Sprint velocity: 40 points per sprint"]
- ...

## Open Questions
- [OQ-0001]: [Question affecting plan — e.g., "Availability of staging environment?"]
- ...

## Main Content

### Plan Overview

| Metric | Value |
|--------|-------|
| Total Phases | [N] |
| Total Sprints | [N] |
| Total Duration | [N] weeks |
| Total Effort | [N] points |
| Sprint Velocity | [N] points/sprint |
| Critical Path Length | [N] points ([N] sprints) |
| Total Risks | [N] (P0: [N], P1: [N], P2: [N]) |

### Phase Plan

#### Phase 0: Foundation
- **Duration**: Sprint 1 ([dates])
- **Epics**: EPIC-0001
- **Goal**: [What is achieved when this phase completes]
- **Exit Criteria**:
  - [ ] [Verifiable criterion 1]
  - [ ] [Verifiable criterion 2]

#### Phase 1: Core MVP
- **Duration**: Sprints 2-4 ([dates])
- **Epics**: EPIC-0002, EPIC-0003, EPIC-0004
- **Goal**: [What is achieved when this phase completes]
- **Exit Criteria**:
  - [ ] [Verifiable criterion 1]
  - [ ] [Verifiable criterion 2]
  - [ ] [Verifiable criterion 3]

#### Phase 2: Enhancement
- **Duration**: Sprints 5-6 ([dates])
- **Epics**: EPIC-0005, EPIC-0006
- **Goal**: [What is achieved when this phase completes]
- **Exit Criteria**:
  - [ ] [Verifiable criterion 1]
  - [ ] [Verifiable criterion 2]

#### Phase 3: Optimization
- **Duration**: Sprints 7-8 ([dates])
- **Epics**: EPIC-0007
- **Goal**: [What is achieved when this phase completes]
- **Exit Criteria**:
  - [ ] [Verifiable criterion 1]
  - [ ] [Verifiable criterion 2]

### Sprint Breakdown

#### Sprint 1: Foundation Setup
- **Phase**: 0
- **Duration**: Weeks 1-2
- **Capacity**: [N] points (after 20% buffer)
- **Planned**: [N] points

| Task | Title | Size | Points | Critical Path |
|------|-------|------|--------|---------------|
| TASK-0001 | [Title] | M | 4 | Yes |
| TASK-0002 | [Title] | S | 2 | Yes |
| TASK-0003 | [Title] | M | 4 | No |

**Sprint Goal**: [One sentence]
**Milestone**: [Deliverable]

#### Sprint 2: Core Feature Development
- **Phase**: 1
- **Duration**: Weeks 3-4
- **Capacity**: [N] points
- **Planned**: [N] points

| Task | Title | Size | Points | Critical Path |
|------|-------|------|--------|---------------|
| TASK-0004 | [Title] | L | 8 | Yes |
| TASK-0005 | [Title] | M | 4 | No |
| TASK-0006 | [Title] | S | 2 | No |

**Sprint Goal**: [One sentence]
**Milestone**: [Deliverable]

[... additional sprints ...]

### Critical Path

```mermaid
gantt
    title Critical Path Timeline
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Phase 0
    [Task Name]    :crit, t1, [date], [duration]
    [Task Name]    :crit, t2, after t1, [duration]

    section Phase 1
    [Task Name]    :crit, t3, after t2, [duration]
    [Task Name]    :t4, after t2, [duration]
    [Task Name]    :crit, t5, after t3, [duration]

    section Phase 2
    [Task Name]    :t6, after t5, [duration]

Critical Path Summary:

TASK-0001 → TASK-0004 → TASK-0007 → TASK-0010 → TASK-0015
Total: [N] points, [N] sprints, [N] weeks

Float Analysis:

Task	Float (points)	Float (days)	Notes
TASK-0005	4	2	Can slip 2 days without affecting deadline
TASK-0006	8	4	Low priority, significant buffer

Risk Mitigation

P0 Risks (Immediate Attention Required)

RISK-0001: [Risk Title]

• Category: Technical
• Probability: High
• Impact: High
• Severity: P0
• Description: [What could go wrong]
• Affected Tasks: TASK-0004, TASK-0007
• Mitigation Strategy: [Proactive steps to reduce probability or impact]
• Contingency Plan: [Reactive steps if risk materializes]
• Owner: [Role]
• Trigger: [Observable indicator]

RISK-0002: [Risk Title]

• Category: External
• Probability: Medium
• Impact: High
• Severity: P0
• Description: [What could go wrong]
• Affected Tasks: TASK-0008
• Mitigation Strategy: [Steps]
• Contingency Plan: [Steps]
• Owner: [Role]
• Trigger: [Indicator]

P1 Risks (Monitor Closely)

RISK-0003: [Risk Title]

• Category: Schedule
• Probability: Medium
• Impact: Medium
• Severity: P1
• Description: [What could go wrong]
• Affected Tasks: TASK-0010, TASK-0011
• Mitigation Strategy: [Steps]
• Contingency Plan: [Steps]
• Owner: [Role]
• Trigger: [Indicator]

[... additional P1 risks ...]

P2 Risks (Track)

RISK-0004: [Risk Title] [... same format ...]

Risk Heat Map

Category	P0	P1	P2
Technical	[N]	[N]	[N]
Resource	[N]	[N]	[N]
External	[N]	[N]	[N]
Scope	[N]	[N]	[N]
Schedule	[N]	[N]	[N]
Quality	[N]	[N]	[N]

Definition of Done

Task-Level DoD

• Code written and self-reviewed
• Unit tests written and passing (minimum 80% coverage for new code)
• Code review approved by at least one team member
• No new linting errors or warnings
• Acceptance criteria from TASK-NNNN verified
• No regression in existing tests

Sprint-Level DoD

• All planned tasks meet task-level DoD
• Integration tests passing for completed features
• No critical or high-severity bugs open from this sprint
• Sprint review/demo completed with stakeholders
• Sprint retrospective conducted
• Documentation updated for completed features
• Deployment to staging environment successful

Phase-Level DoD

• All sprint-level DoDs met for all sprints in phase
• Phase exit criteria verified and signed off
• End-to-end tests passing for all phase features
• NFR benchmarks met (performance, security, reliability)
• Security review completed (if phase includes auth or data features)
• Technical debt documented and tracked

Release DoD

• All phase-level DoDs met
• Production deployment successful
• Smoke tests passing in production
• Monitoring and alerting operational and verified
• Rollback procedure documented and tested
• User-facing documentation complete
• Support team briefed and trained
• Post-deployment verification checklist complete

Milestones

Milestone	Sprint	Phase	Date	Deliverable
M1: Infrastructure Ready	Sprint 1	0	[Week 2]	CI/CD pipeline, database, auth setup
M2: MVP Feature Complete	Sprint 4	1	[Week 8]	All P0 features functional
M3: Beta Ready	Sprint 6	2	[Week 12]	P0+P1 features, performance validated
M4: Production Release	Sprint 8	3	[Week 16]	All features, hardened, monitored

Acceptance Criteria

• All epics assigned to phases with clear rationale
• All tasks assigned to sprints respecting dependencies
• Sprint capacity not exceeded (planned points <= capacity)
• Critical path identified with Gantt visualization
• At least one risk per mandatory category (Technical, Resource, External, Scope, Schedule, Quality)
• P0 risks have both mitigation strategies and contingency plans
• Definition of done defined at task, sprint, phase, and release levels
• Milestones defined with dates and deliverables
• All IDs sequential and sorted per determinism rules
• Phase exit criteria are objectively verifiable

**Output path**: `artifacts/greenfield/<project_name>/IMPLEMENTATION_PLAN.md`

## Determinism Rules

1. RISK-NNNN IDs: Sort by severity first (P0 before P1 before P2), then alphabetically by risk title within each severity level. Assign sequential 4-digit numbers starting from 0001.
2. ASM-NNNN IDs: Sort alphabetically by assumption text, assign sequential numbers
3. OQ-NNNN IDs: Sort alphabetically by question text, assign sequential numbers
4. Phases ordered numerically (Phase 0, 1, 2, 3)
5. Sprints ordered numerically within phases
6. Tasks within sprints ordered by critical path first, then by TASK-NNNN number
7. Risks within each severity group ordered alphabetically by title
8. No timestamps in artifact body (use relative dates like "Week 1-2" or placeholder dates)
9. Sections must appear in template order

## Sprint Planning Heuristics

### Velocity Estimation
- **New team, new technology**: 20-30 points per sprint (high uncertainty)
- **Established team, new project**: 30-40 points per sprint
- **Established team, familiar domain**: 40-60 points per sprint
- **Adjust after Sprint 1**: Use actual velocity for future sprints

### Capacity Planning
- **Available capacity** = velocity * (1 - buffer%)
- **Buffer**: 20% for interrupts, bugs, meetings (default)
- **Sprint 1 buffer**: 30% (setup overhead, unfamiliarity)
- **Phase transition sprints**: 25% buffer (context switching)

### Task Ordering Within Sprints
1. Critical path tasks first (any delay cascades)
2. Tasks with most dependents next (unblocks other work)
3. Highest risk tasks early (fail fast)
4. Test tasks follow their implementation tasks
5. Documentation tasks last (lowest risk of delay)

## Quality Checklist

Before completing, verify:
- [ ] All epics are assigned to phases
- [ ] Phase dependencies are valid (no backward references)
- [ ] All tasks are assigned to sprints
- [ ] Sprint planned points do not exceed capacity
- [ ] Dependencies are respected in sprint assignments
- [ ] Critical path is identified and visualized
- [ ] At least 6 risks documented (one per mandatory category)
- [ ] P0 risks have mitigation strategies AND contingency plans
- [ ] Risk IDs are sorted by severity then alphabetically
- [ ] Definition of done is defined at all four levels
- [ ] Milestones have dates and deliverables
- [ ] Float analysis shows non-critical task flexibility
- [ ] Phase exit criteria are objectively verifiable
- [ ] All IDs are sequential and deterministically ordered
- [ ] Artifact follows the standard template structure

## Common Pitfalls

1. **No buffer in sprint capacity**: Teams never operate at 100% capacity. Always include 20%+ buffer for interrupts, bugs, and meetings.
2. **Ignoring the critical path**: If you do not know the critical path, you cannot optimize for delivery speed. Any delay on the critical path delays the entire project.
3. **Risks without contingency plans**: Mitigation reduces probability, but if the risk still materializes, you need a contingency. P0 risks MUST have both.
4. **Phase exit criteria that are subjective**: "Code is good quality" is subjective. "All tests pass, code coverage > 80%, zero critical bugs" is objective.
5. **Sprint 1 overloaded**: The first sprint always has setup overhead. Plan for 70% capacity in Sprint 1.
6. **No milestones**: Without milestones, progress is invisible to stakeholders. Define at least one milestone per phase.
7. **Risks that are too generic**: "Something might go wrong" is not a risk. "Third-party payment API has 99.5% SLA, meaning ~3.6 hours of downtime per month, which could block order processing" is a risk.
8. **Missing resource risks**: Key person dependency is one of the most common project risks. If only one person can work on a critical component, that is a P0 resource risk.
9. **Definition of Done too strict for early phases**: Phase 0 DoD should focus on infrastructure readiness, not feature completeness. Adapt DoD to the phase context.
10. **No rollback strategy**: Every release plan must include how to revert if the deployment fails. "We'll figure it out" is not a rollback strategy.