Plan Mode: Structure Complex Work

Plan Mode transforms overwhelming goals into manageable steps. While Agent Mode delegates execution, Plan Mode focuses on organizing—creating the roadmap you or others will follow.

What Plan Mode Is For

Plan Mode excels at:

Project roadmaps: “Create a 90-day plan to launch our MVP”
Learning paths: “Plan how to learn Kubernetes in 60 days”
Implementation guides: “Create a migration plan from monolith to microservices”
Content calendars: “Plan 3 months of blog content”
Process design: “Design an onboarding workflow for new engineers”

The common thread: organizing complex work into sequential, actionable steps.

Plan Mode vs. Other Modes

flowchart TD
    A[Ask Mode] --> |"What should I do?"| B[Information]
    C[Strategy Mode] --> |"What's the right choice?"| D[Decision]
    E[Plan Mode] --> |"How do I execute?"| F[Roadmap]
    G[Agent Mode] --> |"Do this complex thing"| H[Execution]

Ask Mode tells you what you should know
Strategy Mode tells you what you should decide
Plan Mode tells you how to execute, step by step
Agent Mode does the execution

The Anatomy of a Good Plan

flowchart LR
    A[Goal Definition] --> B[Phase Breakdown]
    B --> C[Step Details]
    C --> D[Dependencies]
    D --> E[Success Criteria]

1. Goal Definition

What exactly are you trying to achieve? When will you know you’re done?

2. Phase Breakdown

What are the major stages of work?

3. Step Details

What specific actions comprise each phase?

4. Dependencies

What must happen before something else can begin?

5. Success Criteria

How do you verify each step/phase is complete?

Plan Mode Patterns

The Project Plan Pattern

Create a comprehensive plan for a defined project.

Template:

Create a [timeframe] plan to [achieve goal].

Context:
- Current state: [where you are now]
- Desired state: [where you want to be]
- Resources: [what you have available]
- Constraints: [limitations to consider]

Include:
- Phases with milestones
- Weekly or daily breakdown
- Dependencies between tasks
- Risk factors and mitigation
- Success metrics for each phase

Example:

Create a 12-week plan to launch a SaaS product.

Context:
- Current state: Validated idea, no code yet
- Desired state: Live product with 10 paying customers
- Resources: 2 developers (part-time), $5K budget
- Constraints: Must launch before Q4

Include:
- Development phases with milestones
- Weekly task breakdown
- Marketing/sales activities in parallel
- Key dependencies
- What "done" looks like for each phase

The Learning Plan Pattern

Structure skill acquisition systematically.

Template:

Create a [timeframe] learning plan for [skill/topic].

Starting level: [current knowledge]
Target level: [desired competency]
Time available: [hours per week]
Learning style: [preferences]

Include:
- Progressive skill building
- Resources for each phase
- Practice projects
- Checkpoints to verify progress

Example:

Create a 60-day learning plan for Kubernetes.

Starting level: Solid Docker knowledge, basic cloud experience
Target level: Able to deploy and manage production workloads
Time available: 10 hours per week
Learning style: Prefer hands-on projects over video courses

Include:
- Weekly focus areas
- Specific resources (docs, tutorials, courses)
- Practical exercises for each week
- A capstone project
- How to verify I'm ready to use K8s professionally

The Migration Plan Pattern

Structure transition from one state to another.

Template:

Create a migration plan from [current] to [target].

System context: [relevant details]
Risk tolerance: [low/medium/high]
Downtime acceptable: [yes/no/limited]

Include:
- Pre-migration preparation
- Migration phases
- Rollback procedures
- Validation steps
- Post-migration tasks

Example:

Create a migration plan from PostgreSQL 12 to PostgreSQL 16.

System context: Production database, 500GB, serving web application
Risk tolerance: Low (this is our primary database)
Downtime acceptable: 30-minute window on Sunday night

Include:
- Pre-migration testing approach
- Step-by-step migration procedure
- Rollback procedure if issues arise
- Data validation queries
- Post-migration monitoring checklist

The Process Plan Pattern

Design repeatable workflows.

Template:

Design a [process name] workflow.

Trigger: [what initiates the process]
End state: [what completion looks like]
Participants: [who's involved]
Frequency: [how often this happens]

Include:
- Step-by-step procedure
- Responsibilities at each step
- Decision points and criteria
- Templates or checklists needed
- Exception handling

Example:

Design a code review workflow for our team.

Trigger: Developer opens a pull request
End state: Code merged to main branch
Participants: Author, 2 reviewers, CI system
Frequency: Multiple times daily

Include:
- PR preparation steps for author
- Review criteria for reviewers
- Approval requirements
- Merge procedure
- What to do if reviews conflict

The Content Plan Pattern

Structure content creation over time.

Template:

Create a [timeframe] content plan for [channel/purpose].

Goals: [what you want to achieve]
Audience: [who you're creating for]
Resources: [creation capacity]
Constraints: [any limitations]

Include:
- Content themes/pillars
- Specific topics with rationale
- Publishing schedule
- Promotion strategy for each piece
- Metrics to track

Example:

Create a 3-month content plan for our engineering blog.

Goals: Establish thought leadership, attract senior developers
Audience: Senior engineers and engineering managers
Resources: Can publish 2 posts per week
Constraints: Must tie content to our product (DevOps tooling)

Include:
- Content pillars/themes
- 24 specific post topics with brief descriptions
- Publishing cadence
- SEO keywords to target
- How to promote each post

Making Plans Actionable

Specific Next Actions

Vague: “Week 1: Start development” Actionable: “Week 1: Set up project repository, configure CI/CD pipeline, create database schema”

Clear Ownership

For team plans, specify who does what:

“Backend team: Implement authentication endpoints”
“Design: Deliver final mockups by Wednesday”

Measurable Milestones

Unmeasurable: “Make good progress on the backend” Measurable: “Complete 5 core API endpoints, all passing tests”

Realistic Timing

Ask for time estimates and buffer:

Include estimated time for each task.
Add 20% buffer for unexpected issues.
Flag tasks that might take longer than expected.

Dependencies Made Explicit

Clearly mark dependencies:
- "Task B cannot start until Task A is complete"
- "Design approval required before development begins"

Plan Mode Best Practices

Start With the End

Define what success looks like before planning how to get there.

Goal: Launch MVP with 10 paying customers
Not: "Build an app"

Break Down Appropriately

Too granular = overwhelming. Too high-level = not actionable.

For a 12-week plan:

Phase level: 3-4 phases of 3-4 weeks each
Week level: 2-4 major tasks per week
Day level: Only for the current/next week

Include Decision Points

Plans shouldn’t be rigid. Build in checkpoints:

Week 4 checkpoint: 
- If user testing reveals major UX issues, extend design phase by 2 weeks
- If core features stable, proceed to marketing phase

Plan for Learning

You won’t know everything upfront. Include:

Research/discovery time
Prototype/validation phases
Pivots if initial assumptions are wrong

Common Plan Mode Mistakes

1. Plans Without Context

Lacking context: “Give me a plan to launch a product” With context: “Give me a plan to launch a B2B SaaS product. I have a working prototype, a team of 3, and need to reach 100 users in 90 days. We have no marketing budget.”

2. Ignoring Dependencies

Tasks often depend on others. Plans that ignore this fail.

3. No Buffer Time

Plans that assume everything goes perfectly always fail. Build in 20-30% buffer.

4. Too Detailed Too Early

Don’t plan Day 47 when you’re on Day 1. Detailed near-term, flexible long-term.

5. Plans Without Priorities

When time is short, what can be cut? What’s essential?

Practice Exercise

Create three plans for real goals:

1. Project Plan Identify a project you want to complete. Create a prompt that includes:

Clear goal definition
Current state and resources
Constraints and timeline
Request for phases, milestones, and dependencies

2. Learning Plan Identify a skill you want to develop. Create a prompt that includes:

Starting and target level
Available time
Learning preferences
Request for resources, practice projects, and checkpoints

3. Process/Workflow Plan Identify a repeatable process you need to design. Create a prompt that includes:

Trigger and end state
Participants and frequency
Request for steps, responsibilities, and exception handling

Review: Are your goals specific? Did you provide sufficient context? Are you asking for actionable steps?

Key Takeaways

Plan Mode creates structured roadmaps, not execution
Good plans include: goal, phases, steps, dependencies, and success criteria
Use appropriate patterns: Project, Learning, Migration, Process, Content
Make plans actionable with specific tasks, clear ownership, and measurable milestones
Build in buffers and decision points—plans should flex
Don’t over-detail the distant future

Next lesson: Strategy Mode—making decisions with clarity.

What's the main output of Plan Mode?

Answers to questions

Modified content

Structured roadmaps with actionable steps

Completed project deliverables

What should a good plan include?

Only the final goal

Every possible detail from day 1 to completion

Technical specifications only

Goal, phases, steps, dependencies, and success criteria

How should timing detail vary in a plan?

Equal detail throughout

Detailed near-term, flexible long-term

Detailed long-term, vague near-term

No timing details needed

What's a common Plan Mode mistake?

Not building buffer time for unexpected issues

Including too many phases

Asking for dependencies

Defining clear milestones