Table of Contents

• When to Use

• Integration

• Planning Phases

• Phase 1: Architecture Design

• Phase 2: Task Breakdown

• Phase 3: Dependency Analysis

• Phase 4: Sprint Planning

• Architecture Design Patterns

• Component Identification

• Component Template

• Component: [Name]

• Task Breakdown Template

• TASK-[XXX]: [Task Name]

• Task Estimation Guidelines

• Dependency Graph

• Sprint Structure

• Sprint [N]: [Focus Area]

• Planned Tasks ([X] story points)

• Deliverable

• Risks

• Dependencies

• Risk Assessment

• Output Format

• Architecture

• System Overview

• Component Diagram

• Components

• Data Flow

• Task Breakdown

• Phase 1: [Name] (Sprint [N]) - TASK-001 through TASK-010

• Phase 2: [Name] (Sprint [M]) - TASK-011 through TASK-020

• Dependency Graph

• Sprint Schedule

• Risk Assessment

• Success Metrics

• Timeline

• Next Steps

• Quality Checks

• Related Skills

• Related Commands

• Examples

Project Planning Skill

Transform specification into implementation plan with architecture design and dependency-ordered tasks.

Delegation

For detailed task planning workflows, this skill delegates to spec-kit:task-planning as the canonical implementation. Use this skill for quick planning needs; use spec-kit for comprehensive project plans.

When To Use

• After specification phase completes

• Need to design system architecture

• Need task breakdown for implementation

• Planning sprints and resource allocation

• Converting requirements into actionable tasks

• Defining component interfaces and dependencies

When NOT To Use

• No specification exists yet (use Skill(attune:project-specification) first)

• Still exploring problem space (use Skill(attune:project-brainstorming) instead)

• Ready to execute existing plan (use Skill(attune:project-execution) instead)

• Need to adjust running project (update plan incrementally, don't restart)

Integration

With superpowers:

• Uses Skill(superpowers:writing-plans) for structured planning

• Applies checkpoint-based execution patterns

• Uses dependency analysis framework

Without superpowers:

• Standalone planning methodology

• Task breakdown templates

• Dependency tracking patterns

Planning Phases

Phase 1: Architecture Design

Activities:

• Identify system components

• Define component responsibilities

• Design interfaces between components

• Map data flows

• Select technologies

Output: Architecture documentation with diagrams

Phase 2: Task Breakdown

Activities:

• Decompose FRs into implementation tasks

• Add testing tasks for each FR

• Add infrastructure tasks

• Add documentation tasks

• Estimate each task

Output: Task list with estimates

Phase 3: Dependency Analysis

Activities:

• Identify task dependencies

• Create dependency graph

• Identify critical path

• Detect circular dependencies

• Optimize for parallelization

Output: Dependency-ordered task execution plan

Phase 4: Sprint Planning

Activities:

• Group tasks into sprints

• Balance sprint workload

• Identify milestones

• Plan releases

• Allocate resources

Output: Sprint schedule with milestones

Architecture Design Patterns

Component Identification

Questions:

• What are the major functional areas?

• What concerns should be separated?

• What components can be developed independently?

• What components can be reused?

Common Patterns:

• Frontend/Backend: Separate UI from business logic

• API Layer: Separate interface from implementation

• Data Layer: Separate data access from business logic

• Integration Layer: Isolate external dependencies

Component Template

Component: [Name]

Responsibility: [What this component does]

Technology: [Stack and tools]

Interfaces:

Dependencies:

• [Component 1]: [What's needed]
• [Component 2]: [What's needed]

Data:

• [Data structure 1]
• [Data structure 2]

Configuration:

• [Config param 1]
• [Config param 2]

Task Breakdown Template

TASK-[XXX]: [Task Name]

Description: [What needs to be done]

Type: Implementation | Testing | Documentation | Infrastructure | Deployment Priority: P0 (Critical) | P1 (High) | P2 (Medium) | P3 (Low) Estimate: [Story points or hours] Dependencies: TASK-XXX, TASK-YYY Sprint: Sprint N Assignee: [Name or TBD]

Linked Requirements: FR-XXX, NFR-YYY

Acceptance Criteria:

• [Criterion 1]
• [Criterion 2]
• Tests passing
• Documentation updated

Technical Notes:

• [Implementation detail 1]
• [Implementation detail 2]

Testing Requirements:

• Unit tests: [What to test]
• Integration tests: [What to test]
• E2E tests: [What to test]

Definition of Done:

• Code complete
• Tests passing
• Code reviewed
• Documentation updated
• Deployed to staging

Task Estimation Guidelines

Story Points (Fibonacci):

• 1 point: < 2 hours, trivial, well-understood

• 2 points: 2-4 hours, straightforward

• 3 points: 4-8 hours, some complexity

• 5 points: 1-2 days, moderate complexity

• 8 points: 2-3 days, significant complexity

• 13 points: 3-5 days, high complexity (consider breaking down)

• 21 points: > 5 days, very complex (MUST break down)

Factors to consider:

• Technical complexity

• Uncertainty/unknowns

• Dependencies on other work

• Testing requirements

• Documentation needs

Dependency Graph

Notation:

TASK-001 (Foundation) ├─▶ TASK-002 (Database schema) │ ├─▶ TASK-003 (Models) │ └─▶ TASK-011 (Data import) └─▶ TASK-004 (Authentication) └─▶ TASK-005 (Auth middleware) └─▶ TASK-010 (Protected endpoints)

Validation:

• No circular dependencies (A depends on B, B depends on A)

• Critical path identified

• Parallel work opportunities identified

• Blocking tasks highlighted

Sprint Structure

Sprint Template:

Sprint [N]: [Focus Area]

Dates: [Start] - [End] Goal: [Sprint objective] Capacity: [Team capacity in story points]

Planned Tasks ([X] story points)

• TASK-XXX ([N] points)
• TASK-YYY ([M] points)
• ...

Deliverable

[What will be demonstrable at sprint end]

Risks

• [Risk 1 with mitigation]
• [Risk 2 with mitigation]

Dependencies

• [External dependency 1]
• [External dependency 2]

Risk Assessment

Risk Template:

Common Risks:

• Technology unknowns

• Third-party API dependencies

• Resource availability

• Scope creep

• Performance issues

• Security vulnerabilities

Output Format

Save to docs/implementation-plan.md :

[Project Name] - Implementation Plan v[version]

Author: [Name] Date: [YYYY-MM-DD] Sprint Length: [Duration] Team Size: [Number] Target Completion: [Date]

Architecture

System Overview

[High-level architecture description]

Component Diagram

[ASCII or markdown diagram]

Components

[Component details using template above]

Data Flow

[How data moves through system]

Task Breakdown

Phase 1: [Name] (Sprint [N]) - TASK-001 through TASK-010

[Tasks using template above]

Phase 2: [Name] (Sprint [M]) - TASK-011 through TASK-020

[Tasks using template above]

Dependency Graph

[Dependency visualization]

Sprint Schedule

[Sprint details using template above]

Risk Assessment

[Risk table]

Success Metrics

• [Metric 1]
• [Metric 2]

Timeline

Next Steps

1. Review plan with team
2. Initialize project with /attune:project-init
3. Start execution with /attune:execute

Quality Checks

Before completing plan:

• ✅ All architecture components documented

• ✅ All FRs mapped to tasks

• ✅ All tasks have acceptance criteria

• ✅ Dependencies are acyclic

• ✅ Effort estimates provided

• ✅ Critical path identified

• ✅ Risks assessed with mitigations

• ✅ Sprints balanced by capacity

Post-Completion: Workflow Continuation (REQUIRED)

Automatic Trigger: After Quality Checks pass and docs/implementation-plan.md is saved, MUST auto-invoke the next phase.

When continuation is invoked:

• Verify docs/implementation-plan.md exists and is non-empty

• Display checkpoint message to user: Implementation plan complete. Saved to docs/implementation-plan.md. Proceeding to execution phase...

• Invoke next phase: Skill(attune:project-execution)

Bypass Conditions (ONLY skip continuation if ANY true):

• --standalone flag was provided by the user

• docs/implementation-plan.md does not exist or is empty (phase failed)

• User explicitly requests to stop after planning

Do NOT prompt the user for confirmation — this is a lightweight checkpoint, not an interactive gate. The user can always interrupt if needed.

Related Skills

• Skill(superpowers:writing-plans)

• Planning methodology (if available)

• Skill(spec-kit:task-planning)

• Task breakdown (if available)

• Skill(attune:project-specification)

• Previous phase

• Skill(attune:project-execution)

• AUTO-INVOKED next phase after planning

• Skill(attune:mission-orchestrator)

• Full lifecycle orchestration

Related Commands

• /attune:blueprint

• Invoke this skill

• /attune:execute

• Next step in workflow

Examples

See /attune:blueprint command documentation for complete examples.

Troubleshooting

Common Issues

If you find circular dependencies in your task graph, break one of the tasks into smaller sub-tasks. If sprint capacity is consistently exceeded, re-estimate tasks using the Fibonacci scale or reduce sprint scope.