Plan vs prompt

Not every task needs a plan. Sometimes you prompt Claude, it executes, done. But for anything multi-step, multi-day, or high-stakes, a 10-minute plan up front prevents 10 hours of rework later. This lesson is about knowing when to plan.

When prompting is enough

• Single-output tasks - "write 3 email subject lines", "summarise this doc"
• You've done the task many times and know the shape
• The output is small enough to review in one pass
• No external stakeholders depend on the output
• Mistakes are cheap to fix

For these, just prompt. Planning would be overhead.

When you need a plan

• Multi-session work - will take more than one session to finish
• Multi-step - 5+ distinct stages with dependencies
• Multi-deliverable - produces several pieces that connect
• First time - you haven't done this task before
• Client-facing at the end - mistakes cost reputation or money
• Complex decisions - where picking the wrong path costs significant time

For these, plan first.

What a plan looks like

Not a Gantt chart. Not a project management doc. A plan for Claude Code is typically

2-4 markdown files

• brief.md - the goal, success criteria, constraints
• plan.md - the steps, in order, with approximate time + dependencies
• spec.md (optional) - detailed requirements for the output
• notes.md (optional) - scratchpad for decisions + learnings as you go

All in your project folder. Claude reads them as needed via @file references.

The cost of no plan

Without a plan, you'll experience some mix of

• Claude solving the wrong problem well
• Building something that looks right but misses the point
• Discovering the real scope halfway through (ugh)
• Context running out before the task is done
• Re-work because decisions weren't thought through
• Mid-project pivots that eat 3x the original time

10 minutes planning → fewer hours of rework. Classic time investment.

The cost of too much plan

The opposite failure: plans so detailed you spend hours planning something that takes 30 minutes to execute.

• Planning turns into procrastination
• Over-specified plans break when reality differs slightly
• You lose the agency + creativity Claude brings to unconstrained problems

Rule: plan for 10% of the total task time. 10-hour task = 1 hour plan. 10-min task = don't plan.

The decision framework

Before starting any non-trivial task, ask

1. Will this take more than 2 sessions? → plan
2. Is a client or team member waiting on the output? → plan
3. Am I doing this type of task for the first time? → plan
4. Could getting the scope wrong cost significant time? → plan
5. Are there multiple reasonable approaches I could take? → plan

Any "yes" = plan. All "no" = prompt and go.

What this module covers

1. This lesson - when to plan
2. Brainstorm + scope the project with Claude
3. Write a plan document
4. Store plan / spec / notes as context files
5. Execute in chunks across sessions

Action items

☐ Memorise the 5-question decision framework

☐ Think about your current projects - which needed a plan but didn't get one?

☐ Rule of thumb: plan time = 10% of total task time Next lesson: Brainstorming a project with Claude.

Exercises

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