🇺🇸English
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**:
- [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
### 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 :
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| [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:
# [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
| Sprint | Dates | Focus | Deliverable |
|--------|-------|-------|-------------|
| 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 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 userdocs/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 phaseSkill(attune:project-execution) - AUTO-INVOKED next phase after planningSkill(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.
Weekly Installs
52
Repository
athola/claude-n…t-market
GitHub Stars
211
First Seen
Jan 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykFail
Installed on
opencode47
codex45
gemini-cli44
claude-code43
cursor41
github-copilot39
