Table of Contents
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
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)
- Still exploring problem space (use
Skill(attune:project-brainstorming)
- Ready to execute existing plan (use
Skill(attune:project-execution)
- Need to adjust running project (update plan incrementally, don't restart)
Integration
With superpowers:
- Uses
Skill(superpowers:writing-plans)
- 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
markdown
### Component: [Name]
**Responsibility**: [What this component does]
**Technology**: [Stack and tools]
**Interfaces**:
- [Interface 1]: [Description]
- [Interface 2]: [Description]
**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
markdown
### 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:
markdown
## 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:
markdown
|------|--------|-------------|------------|
| [Risk description] | High/Med/Low | High/Med/Low | [How to address] |
Common Risks:
- Technology unknowns
- Third-party API dependencies
- Resource availability
- Scope creep
- Performance issues
- Security vulnerabilities
Output Format
Save to
docs/implementation-plan.md
:
markdown
# [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
|--------|-------|-------|-------------|
| 1 | Jan 3-16 | Foundation | Dev environment |
| 2 | Jan 17-30 | Core | Feature X working |
## 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
- 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):
- flag was provided by the user
docs/implementation-plan.md
- 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)
Skill(spec-kit:task-planning)
Skill(attune:project-specification)
Skill(attune:project-execution)
Skill(attune:mission-orchestrator)
Related Commands
- - Invoke this skill
- - Next step in workflow
Examples
See
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.