The Plan

Small ordered steps, without the overwhelm

A plan breaks the agreed spec into a list of small steps, built and checked one at a time. Here's the part nobody tells you: a real plan is full of technical words, and you don't need to read most of them. You're not writing the code. You're checking the shape.

The brief→ The spec→ The plan
How to read one without drowning

What to read, and what to skim

When Claude hands you a plan, your eyes will hit file names, commands and code. Breathe. Most of that is Claude's notes to itself. Here's where to actually look.

Read this
  • The goal at the top, is it the thing you agreed?
  • The list of phases and the order they're built in
  • That each phase is working software you could actually see
  • The traps it flags (a good plan names the risky bits up front)
Skim this
  • File names and folders (src/lib/...)
  • The tech-stack list (the tools Claude will use)
  • Code blocks and commands
  • Anything that looks like it's written for a machine
None of this needs your sign-off. It's the how, and the how is Claude's job.
So before you say "go," check four things:
  1. Is it broken into small phases, not one giant leap?
  2. Is each phase something you could see working?
  3. Are they in a sensible order (the core thing first)?
  4. Does it follow the spec you already agreed?
What a good plan looks like

Retention Pulse, as seven plain steps

Strip the code away and a good plan is just this: an ordered list of working stages, each with a clear finish line. This is the shape underneath all the technical words.

PHASE 1

Work out who counts as a member, and pull in the whole roster

Done when the app shows honest member numbers, not a borrowed list.
PHASE 2

Lay down the look and the page frame

Done when it's on-brand and you can move between pages.
PHASE 3

Build the main triage list and the click-in member detail

Done when you can click a member and see exactly why they're at risk.
PHASE 4

Build the calm home screen

Done when opening the app shows you the few who need you today, at a glance.
PHASE 5

Build the remaining pages

Done when every member has a home (today, suspensions, cancelling, all members).
PHASE 6

Wire up the actions

Done when you can act on a member, not just look at them (message, snooze, mute).
PHASE 7

Put it live, securely

Done when it's online, password-protected, and only you can see your data.
And here's mine

The real plan, with a safety switch

This is the actual plan that built the app. It has the dev language in it. So flip the switch: read it in plain English, or see the real technical version. You're always one tap from understanding.

Show me:
Retention Pulse v2 — Implementation Plan
docs/plans/retention-pulse-v2.md
The goal

Rebuild Retention Pulse so it works off the real "who's a member" rule across the whole roster, in the premium look, giving a manager a calm, honest worklist that beats Recovr.

The roadmap

Seven phases, each one working software, built in order

  1. Eligibility router + full-roster data
  2. Design system + app shell
  3. Triage rebuild (light rows + member peek)
  4. Home (the calm landing)
  5. Today, Suspensions, Cancelling, All Members
  6. Actions (message, snooze, mute)
  7. Deploy
Why it's good
"Seven phases, each one software I can actually look at, built in order. I'm never left staring at a half-built thing wondering if it works."
The traps it flags

A heads-up about a command that would wipe the data

Claude notes that the obvious way to change the database would accidentally erase everything, and writes down the safe way to do it instead. You don't need the commands. What matters is that the plan caught the trap before it cost a day.

Critical repo gotchas

NO `prisma migrate dev` # proposes a reset that DROPS all data use: npx prisma db push then: rm -rf .next && npx prisma generate # after any schema change, clear .next — Turbopack caches the stale client
Why it's good
"I made Claude write down the traps that waste a day or wipe data. That section looks scary, but it's Claude protecting me, not noise to be afraid of."
The first small step

Add three new facts about each member

Before anything clever, give each member three new bits of info: their package type, when they were sold their membership, and when they first joined. That's what lets the app tell a real member apart from an intro offer or a free comp.

Task 1, Step 1: add eligibility fields to the schema

// prisma/schema.prisma (Member model) packageCategory String? // Memberships | Intro | ... dateSold DateTime? // new-member detection memberCreatedDate DateTime? // old date + recent sale = upgrade
Why it's good
"Only Phase 1 is spelled out this deep. The rest get detailed when we reach them, so the steps stay accurate as the code changes. A plan that plans everything up front is usually wrong by step three."
Agreed and ordered

Now the build is just working the list

With the plan agreed, building is no longer a leap into the unknown. It's one small, checkable step at a time, exactly as written. That's the next tab.

Up next · The Build