module 11 plan projects

Write a plan

System Text-to-Speech Ready
Slide: 0:00 / 0:00
Slide 1 of 0Interactive Deck

Full Lesson Reference

You have a brief. Now you need a plan - the steps that turn the brief into reality. The /writing-plans skill (part of the superpowers pack) guides this. Without it, manual prompting works too.

What a plan document contains

  • Phases - major chunks of work with clear purpose
  • Steps within each phase - specific tasks in rough order
  • Dependencies - what needs to finish before the next thing starts
  • Checkpoints - natural stopping points to review progress
  • Time estimates - rough sizing per phase
  • Risks - what could go wrong, how you'd adjust

Output goes into plan.md in the project folder.

Using the writing-plans skill (from the superpowers pack)

terminal
/writing-plans

Read the brief.md in this project. Draft a plan.md that breaks the work into phases, each with steps, dependencies, rough time estimates, and risks. Target 4-6 phases total.

The skill

  1. Reads your brief
  2. Proposes a phase breakdown
  3. Asks you to refine or approve
  4. Fills in the details for each phase
  5. Writes the plan.md file Manual plan writing

Without the skill

Read brief.md. Draft a plan.md with

  • 4-6 phases, each with a clear goal
  • Steps inside each phase
  • Dependencies between phases
  • Rough time estimate per phase
  • 1-2 risks per phase + what you'd do if they happen

Don't fill in details until I approve the phase structure.

Claude proposes phases first. You approve or adjust. Then Claude fills the detail. Iterative approach prevents you getting buried in a 100-line plan that doesn't reflect your thinking.

Anatomy of a good plan

Q1 Growth Report - Plan

Phase 1: Data pulls (est. 30 min)

Goal: all data for the report lives in the project folder

Steps

  1. Pull Google Ads last 90 days from warehouse
  2. Pull Meta Ads last 90 days
  3. Pull Klaviyo email performance last 90 days
  4. Pull GA4 organic traffic + conversions
  5. Save all to data/ folder, named by source + date range

Dependencies

None - can start immediately

Risks

  • Data freshness in warehouse (check before starting)
  • Missing data for Feb due to known attribution gap

Phase 2: Analysis (est. 45 min)

Goal: identify the 3-5 insights that actually drive the report

Steps

  1. YoY comparison for each channel
  2. Identify the biggest positive + negative mover
  3. Cross-check the Meta Feb drop - real or attribution?
  4. SEO traffic - algo vs ranking analysis
  5. Write insights.md with the 5 most important findings

Dependencies

Phase 1 complete

Risks

  • Analysis reveals the report shouldn't be in this shape (revisit brief if so)

Phase 3: Report draft (est. 60 min) ... etc

Phase 4: Client review + revisions (est. 30 min) ... etc

Phase 5: Finalise + encrypt + publish (est. 15 min) ... etc

What a good plan is NOT

  • A 5-page document nobody reads
  • Hour-by-hour scheduling (too rigid)
  • Every possible step listed (over-specified)
  • Written before you understand what's hard (premature)
  • Locked in - plans should flex as you learn

The plan evolves

Once you're executing the plan, update it as reality unfolds. When a phase finishes:

Update plan.md - mark Phase 1 complete. Note what went as planned and what surprised us. Adjust remaining phases if our learnings should change them.

Claude appends to the plan with your learnings. Future-you (or next-session-you) sees the arc of the project.

Deciding on architecture decisions upfront

For projects with design choices - "should the report be one long scroll or a multi-page PDF?" - surface the decision in the plan:

Architecture decisions (resolve before Phase 3)

  • Report format: single HTML scroll vs multi-page deck
  • Chart library: Chart.js vs custom SVG vs static PNG
  • Data source of truth: warehouse vs live MCP pulls

You tick these off as decisions are made. Prevents re-litigating them later.

Power-user tips

  • Write rough, not polished - plans are tools, not deliverables
  • 4-6 phases is usually right - fewer = too coarse, more = too granular
  • Time estimates are for calibration, not prediction - don't beat yourself up if you're over
  • Risks + mitigations matter more than steps - steps get figur ed out, risks can derail you
  • Save plan.md to project folder - Claude references it at the start of future sessions

Action items

☐ If you have the superpowers pack installed (from Lesson 2), /writing-plans works out of the box

☐ For your next planned project, write plan.md based on brief.md

☐ Target 4-6 phases with steps + dependencies + risks

☐ Update plan.md as you complete phases

Next lesson: Storing plans as context files.

Exercises

  1. Review the concepts covered in this lesson: Write a plan.
  2. Write down your key takeaway from this lesson.
  3. Practice running any commands or prompts mentioned above inside your terminal.