Use when creating architecture plans. Trigger with /plan project or design system requests.
This skill teaches orchestrators how to create comprehensive planning documents that guide projects from conception to execution. Planning patterns enable you to design system architecture, identify risks, create execution sequences, and break work into actionable tasks.
Use this skill when:
Execute these phases in order:
Copy this checklist and track your progress:
This skill produces comprehensive planning documentation across four sequential phases:
| Phase | Output Artifact | Contents |
|---|---|---|
| Architecture Design | Architecture design document | System components, responsibilities, data flows, dependencies, interfaces, design patterns |
| Risk Identification | Risk register | Prioritized risks, impact/probability assessments, mitigation strategies, monitoring plans |
| Roadmap Creation | Master roadmap | Phases, execution sequence, milestones, deliverables, resource allocation, effort estimates |
| Implementation Planning | Task implementation plan | Detailed tasks, ownership assignments, dependency network, success criteria, tracking mechanisms |
This skill teaches four specific planning activities executed in sequence:
| Activity | Output | Effort Level |
|---|---|---|
| Architecture Design | System architecture document | Significant |
| Risk Identification | Risk register | Moderate |
| Roadmap Creation | Execution sequence with phases/milestones | Moderate |
| Implementation Planning | Detailed task list with ownership | Moderate |
Before diving into details, understand the four-phase process and how they connect.
Read first: step-by-step-procedures.md
Companion checklist: planning-checklist.md
Read: architecture-design.md
| Your Need | Section to Read |
|---|---|
| List all system components | Step 1: Identify System Components |
| Define what each component does | Step 2: Define Component Responsibilities |
| Understand how data moves | Step 3: Map Data Flows |
| Identify component dependencies | Step 4: Identify Component Dependencies |
| Define communication contracts | Step 5: Define Component Interfaces |
| Find proven design patterns | Common Architecture Patterns |
| Start your architecture document | Architecture Design Document Template |
Output: Architecture design document with all components mapped
Read: risk-identification.md
| Your Need | Section to Read |
|---|---|
| Find all possible risks systematically | Discover All Risks |
| Evaluate risk impact and probability | Assess Impact and Probability |
| Find mitigation strategies | Plan Mitigation Strategies |
| Document risks formally | Risk Register Template |
| Track risks over time | Monitoring Plan Definition |
Output: Risk register with prioritized risks and mitigations
Read: roadmap-creation.md
| Your Need | Section to Read |
|---|---|
| Group work into logical phases | Step 1: Define Phases |
| Order phases by dependencies | Step 2: Sequence Phases Based on Dependencies |
| Define achievement points | Step 3: Define Milestones and Deliverables |
| Allocate people and estimate timing | Step 4: Allocate Resources and Estimate Effort |
| Create complete roadmap | Step 5: Create the Master Roadmap |
Output: Detailed roadmap with phases, execution sequence, milestones, resources
| Your Need | Section to Read |
|---|---|
| Decompose milestones into work units | Step 1: Break Down Milestones into Tasks |
| Find the critical path | Step 2: Create Dependency Network |
| Assign work to team members | Step 3: Assign Owners and Create Responsibility Matrix |
| Daily tracking during execution | Step 4: Create Daily/Weekly Tracking |
Output: Detailed task list with ownership, execution sequence, success criteria
Important: Even under pressure, do all four phases. Do them faster, not skip them.
| Concept | Definition |
|---|---|
| Architecture | Blueprint of how your system is organized: components, responsibilities, communication |
| Risk | Something that could prevent you from reaching your goal |
| Roadmap | Sequenced plan showing what will be built, in what order, with what dependencies |
| Milestone | Significant achievement or completion point marking end of phases |
| Task | Small, focused unit of work that one person can complete |
| Problem | Solution |
|---|---|
| Architecture is too complex | Break complex components into smaller sub-components with single responsibility |
| Risks are everywhere | Prioritize by impact x probability. Focus on CRITICAL and IMPORTANT risks |
| Progress stalls | Check buffer capacity. If 100% utilization, add buffer work capacity |
| Team does not understand plan | Create multiple formats: executive summary, visual sequence, milestone checklist |
| Plan became irrelevant | Revisit and update plan as conditions change |
| Task owners overcommitted | Reduce tasks, adjust scope, or add team members |
Project: Build user authentication system
Phase 1 - Architecture:
- Components: auth-service, user-store, token-manager
- Data flows: login request → auth-service → user-store → token-manager → JWT
- Dependencies: auth-service depends on user-store
Phase 2 - Risks:
- Risk 1: OAuth provider rate limits (HIGH impact, MEDIUM probability)
- Mitigation: Implement caching, prepare fallback providers
Phase 3 - Roadmap:
- Milestone 1: Basic login (Week 1-2)
- Milestone 2: OAuth integration (Week 3-4)
- Milestone 3: Token refresh (Week 5)
Phase 4 - Tasks:
- Task 1.1: Create user schema (Owner: Dev A, 2 days)
- Task 1.2: Implement password hashing (Owner: Dev B, 1 day)
1. Quick architecture: Focus on 3 critical components only
2. Quick risks: Identify top 5 blocking risks
3. Quick roadmap: Define critical path only
4. Detailed next phase: Plan immediate tasks
5. Rough remaining phases: Detail later as needed
| Reference | Use When |
|---|---|
| step-by-step-procedures.md | Getting the big picture |
| architecture-design.md | Designing system structure |
| risk-identification.md | Identifying obstacles |
| roadmap-creation.md | Creating execution plan |
| implementation-planning.md | Breaking work into tasks |
| planning-checklist.md | Verifying completeness |
For plan validation and quality enforcement, see enforcement-mechanisms.md:
For all utility scripts, see scripts-reference.md:
For TDD integration with planning, see tdd-planning.md:
For handling user requirements, see requirement-immutability.md:
| Resource | Location |
|---|---|
| Plan format template | resources/plan-format.md |
| Plan diff specification | resources/diff-format.md |
| Plan verification guide | plan-verification-guide.md |
| GitHub issue linking | plan-file-linking.md |
| Phase | Purpose | Deliverable |
|---|---|---|
| Architecture Design | Design system blueprint | Architecture document |
| Risk Identification | Discover obstacles | Risk register |
| Roadmap Creation | Create execution sequence | Roadmap with phases |
| Implementation Planning | Create task list | Task assignments |
Key Principles:
| Issue | Cause | Solution |
|---|---|---|
| Plan not progressing | Dependencies unclear or blocking | Review dependency graph with tldr arch, identify critical path blockers, escalate to stakeholders |
| Roadmap phases out of order | Incorrect dependency sequencing | Use dependency_resolver.py to validate dependency order, rebuild phase sequence |
| Stakeholders reject plan | Misaligned expectations or missing requirements | Review requirement-immutability.md, verify Requirement Compliance Table, schedule stakeholder alignment meeting |
| Tasks too large to estimate | Insufficient decomposition | Apply task splitting: no task >3 days. Break into sub-tasks with clear acceptance criteria |
| Risk mitigation strategies failing | Risk assessment inaccurate | Update risk register with actual realized risks, adjust impact/probability scores, revise mitigation strategies |
| Team not following plan | Plan unclear or inaccessible | Create multiple formats (executive summary, visual roadmap, daily checklist), ensure plan visibility |
| Plan validation script failing | Quality thresholds not met | Run validate_plan.py with --verbose, address specific violations in order of priority |
| Architecture becomes obsolete | System evolved differently than planned | Schedule architecture review, update component diagram, revise affected phases |
references/step-by-step-procedures.md for process overviewFinal Note: Perfect planning is impossible. Good planning is achievable. The goal is to think through the major decisions before executing, so that execution is smooth and changes are managed, not chaotic.