Plan project

Project Planning Playbook

Authored by Claude Fable 5, to be executed by any model. Follow the phases in order. Each phase ends with a gate — a condition you must satisfy before moving on. The gates are the skill. Skipping them produces plans that read well and fail in week two.

Why this exists

Weak plans fail the same three ways every time: they're built on an imagined version of the codebase instead of the real one, they slice work horizontally ("build the data layer, then the UI") so nothing is testable until the end, and they hide the risky unknowns in the middle where they explode late. Every step below exists to prevent one of those three failures.

Phase 0 — Orient (never plan from memory)

Before writing a single plan line:

1. Read the project's CLAUDE.md and WORK_STATUS.md (top section first) if they exist. They contain architecture rules the plan must not violate and half-finished work the plan must account for.
2. Skim the actual directory structure and the 3–5 files most relevant to the goal. You are checking your assumptions against reality — the conversation's description of the codebase is often 20% stale.
3. Note any hard constraints you find: platform limits, API caps, frozen contracts, deployment quirks.

Gate: you can name at least three concrete facts about the current state (files, patterns, constraints) that you did NOT know from the conversation alone. If you can't, you haven't looked hard enough.

Phase 1 — Scope interview

Ask the user (in one batch, not a drip-feed) whatever is genuinely unknown from this list. Skip questions the context already answers:

• Quality tier: polished production feature, working prototype, or quick experiment? (This changes everything downstream — testing depth, edge cases, polish.)
• Definition of done: what does the user need to SEE working to call this finished?
• Time/effort appetite: one session? A week of sessions?
• Must-have vs. nice-to-have: which parts can be cut if it runs long?
• Users/stakeholders: who else touches this code or reviews this work?

Gate: you have an explicit quality tier and an explicit definition of done, in the user's own words. Do not infer these — they are the two answers people most often assume wrongly on each other's behalf.

Phase 2 — Decompose into vertical slices

Break the work into phases where every phase ends with something the user can run, see, or test. "Set up the data model" is not a phase ending — "add an item and see it persist after reload" is. Horizontal layers feel organized but defer all risk to the integration step at the end; vertical slices surface integration pain in phase 1 where it's cheap.

For each slice, write:

• Name and one-line outcome (what becomes demonstrable)
• Files/systems touched (from your Phase 0 reading, not guesses)
• Depends on (which earlier slices)
• Risk level and why

Then apply the ordering rule: highest-uncertainty slices go as early as their dependencies allow. If there's a slice you're not sure is even possible (an API might not support it, a library might not do what's hoped), it goes first or gets a small spike phase before it. A plan that saves the scary part for last is a plan for discovering failure at the deadline.

Phase 3 — Risk register

List the 3–6 things most likely to derail the plan. For each: what's the unknown, how you'll find out early (a spike, a question, a test), and the fallback if it goes badly. Be honest here — a risk register with only mild risks means you haven't thought about it, not that the project is safe.

Phase 4 — Write the plan document

Write to docs/plans/PLAN-<short-slug>.md (create the folder if needed) using exactly this structure:

# Plan: <Title>
_Created <date> · Quality tier: <tier> · Status: proposed_

## Goal
<2–3 sentences. Include the user's definition of done verbatim.>

## Current state
<What exists now that this builds on — from Phase 0 facts.>

## Phases
### Phase 1 — <name>
**Outcome:** <what becomes demonstrable>
**Touches:** <files/systems>
**Steps:** <numbered, concrete>
**Verify by:** <how the user confirms this phase worked>
<repeat per phase>

## Out of scope
<Explicitly cut items — this is what protects the timeline.>

## Risks
| Risk | How we find out early | Fallback |

## Open questions
<Anything still needing a user decision, clearly flagged.>

Phase 5 — Present and stop

Summarize the plan in a few sentences (phases, first demonstrable milestone, biggest risk), link the plan file, and stop. Do not start building. The plan is the deliverable of this skill; building begins only when the user says so, and often they'll want to edit the plan first. If the project uses WORK_STATUS.md, add an entry noting the plan was created and where it lives.