---
slug: claude-code-planning-workflow
title: "A Claude Code Planning Workflow: What to Write First"
excerpt: "A Claude Code planning workflow: what to decide before you open the terminal, so it builds the app you meant instead of guessing by prompt four."
primaryKeyword: "Claude Code planning workflow"
publishedAt: 2026-07-04
readingTimeMin: 6
author: "Robert Boylan"
tags:
  - claude-code
  - ai-coding-tools
  - spec-driven-development
  - vibe-coding
  - app-planning
---

You open Claude Code, type one sentence describing your app, and thirty seconds later it's already scaffolding files. That part is genuinely impressive. The part that isn't: by the fourth or fifth prompt, it's built a login flow you never asked for, skipped the one feature you actually cared about, and quietly picked a state management library you've never heard of. None of that was in your instructions, because you never gave it any instructions beyond the first sentence.

This isn't a Claude Code problem specifically. It happens with any AI coding tool you hand a vibe instead of a plan. But Claude Code's version of it is worth naming, because it's fast and confident enough that you don't notice the gaps until you're three files deep. The fix isn't a cleverer first prompt. It's deciding what you're building before you open the terminal at all.

Here's a Claude Code planning workflow that takes about ten minutes up front and usually saves you an afternoon of correcting course later.

## The moment Claude Code starts guessing

Claude Code works by reading your instructions, your repo, and whatever context it can find, then making a plan and executing it. When your instructions are thin, "whatever context it can find" does a lot of the heavy lifting. It infers your intent from patterns in similar codebases it's seen, not from anything specific to your app.

Say you write: "build a habit tracker." Claude Code has to decide, on its own: web or mobile, single user or multi-user, streaks or just checkmarks, whether it needs auth on day one. It will pick answers. They might even be reasonable answers. They almost certainly won't be your answers, and you won't find out where they diverge until you're looking at a feature you didn't ask for.

The problem compounds because Claude Code, like most AI coding tools, works with a limited context window: the amount of the conversation and code it can actually hold in view at once. A few prompts in, earlier decisions start falling out of that window, and by the time you correct one gap, you've usually opened two more. The fix isn't remembering to repeat yourself. It's writing the decisions down once, before session one, so there's something durable to point back to.

## What "before you prompt" actually means

A planning workflow doesn't mean a full product requirements document. It means answering four questions in writing, in this order, before you open Claude Code:

- **What is this, in one paragraph?** Not a feature list yet, just the pitch. "A habit tracker for people who've quit three habit trackers already, because it only tracks one habit at a time and shows a single streak number."
- **What are you explicitly not building yet?** This one gets skipped constantly and it's the highest-leverage line in the whole plan. "No social features. No custom habit icons. No mobile app, web only." Every one of these is a decision Claude Code would otherwise make for you.
- **What are the 3 to 5 features that matter, in priority order?** Not fifteen features. Three to five, ranked, so if Claude Code only gets through half of them in the first session, it built the right half.
- **What does the data actually look like?** Even a rough sketch. "A habit has a name, a target frequency, and a log of dates completed." This single detail prevents more schema flailing than anything else on the list.

If you want the fuller version of what belongs in this kind of document, [what a PRD actually is and why it matters](/what-is-a-prd) covers the shape in more depth. The short version for Claude Code specifically: it doesn't need prose, it needs decisions.

## Where the plan lives so Claude Code actually reads it

Claude Code will happily read a `CLAUDE.md` file at the root of your repo, and it's tempting to just dump your plan in there. Resist that. `CLAUDE.md` is for standing instructions about how you build (stack, conventions, commands, "never" rules), and it should stay stable for months. Your app's feature list, priority order, and data model change every week early on, and mixing a changing plan into a stable rules file makes both worse. [The difference between a rules file and a spec](/blog/agents-md-and-cursorrules-explained) is worth understanding before you decide where anything lives.

Practically: keep the four answers above as a short standalone doc, a markdown file in the repo or a pinned note, whatever you'll actually reopen, and paste the relevant parts into your first Claude Code prompt or session context. Anthropic's own [Claude Code documentation](https://docs.anthropic.com/en/docs/claude-code/overview) recommends giving the model this kind of concrete, structured context up front rather than relying on it to infer scope from a short ask. When the plan changes, update the doc first, then tell Claude Code what changed. The doc is the source of truth; the prompt is just how you hand it over this time.

## A worked example: from vague idea to a Claude Code-ready plan

Say the idea is "an app for splitting bills with roommates." Vague, and if you type exactly that into Claude Code, you'll get a generic splitting app that assumes group logins and probably a currency picker you don't need.

Run it through the four questions instead:

- **Pitch:** "A bill-splitting tool for three roommates who already know each other. No group discovery, no invites beyond a link."
- **Not building:** "No multi-currency. No recurring bill automation yet. No mobile app."
- **Features, ranked:** 1) add an expense and split it evenly or by percentage, 2) see who owes whom, net, 3) mark a debt as settled.
- **Data:** "An expense has an amount, a payer, and a list of who owes a share. A settlement just zeroes out a pair."

That's the whole plan, and it's shorter than this paragraph. Hand it to Claude Code as your first message, in the same shape [a Claude-ready brief](/prd-for/claude) uses, and the first session builds the three features you actually ranked, using a data model that won't need surgery when you add the fourth feature next week. Without it, Claude Code is just as likely to build a group-invite flow you'll delete in a week.

The same four questions work if you're not touching code at all. A founder briefing Lovable or v0 with "an app for splitting bills with roommates" hits the exact same wall, just with different jargon in the output. The tool changes; the gap it fills with guesses doesn't.

## The takeaway

None of this is complicated, which is exactly why it gets skipped. Ten minutes of deciding feels slower than typing one sentence and hitting enter, right up until you're on your third correction of the session. The habit that actually saves time is writing the plan down before the tool starts guessing, not after.

That's the gap Draftlytic closes: you answer a handful of questions about your idea, and it hands you back the pitch, the ranked features, the data model, and the "not building" list, already structured for Claude Code, Cursor, or Lovable, whichever one you open next. The thinking still has to happen. It just doesn't have to start from a blank page.