Plan Heavy with Claude: Plan Mode, DDD, and PRD/ERD as Session Handoffs

If you’ve used Claude Code on anything bigger than a weekend project, you’ve hit this wall: you’re three hours into a feature, specs are passing, and the session ends, usage limit and context compacted into something unrecognizable. You open a fresh session and spend the next twenty minutes re-explaining what you were doing and why.

The fix, for me, isn’t a longer context window. It’s writing the project down before I ask Claude to write any code. How I do that is by writing the part most people skip.

Step Zero: Plan Mode

A new project starts in plan mode. No edits, no commits, no tool calls that change the world. Just a conversation.

I describe what I want to build, the key workflows, the users, and the constraints I already know about. Then I hand the floor over with a prompt I keep around as a snippet:

I'm going to describe a project. Use a Domain-Driven Design (DDD) lens to
find gaps before we write anything down:

- What bounded contexts are implied?
- What entities and aggregates are not named yet?
- Where am I using two words for the same thing, or one word for two different things?
- What domain events does this system react to, or emit?

Ask me whatever you need. Do not propose a schema or write code. We are not leaving plan mode until the questions stop surfacing real ambiguity.

Plan mode is what makes this safe. Claude can’t go off and start creating a web app while I’m still figuring out the gaps, concepts, and use cases. The whole session is a conversation, not a half-built project.

Why use DDD as the lens

I’m not a DDD expert, but I use DDD as a lens because it surfaces the questions I haven’t thought to ask:

• Bounded contexts — where are the seams? Is "user in onboarding" really the same thing as "user in billing"?
• Ubiquitous language — am I using two words for the same thing, or one word for two different things?
• Aggregates and invariants — what must always be true together? What can be eventually consistent?
• Domain events — what actually happens in this system, named in the language of the business?

Most of the questions Claude raises I can answer in a sentence. The interesting ones are the ones that make me stop and think — those are exactly the gaps that would have turned into rewrites later.

Then, and Only Then: PRD and ERD

Once the discovery conversation has converged, I exit plan mode and ask Claude to produce two documents:

• Product Requirements Document (PRD). What we’re building and why. Users, flows, scope, what’s explicitly out of scope. This captures the agreement we just reached. Once it stabilizes, it doesn’t change much.
• Engineering Requirements Document (ERD). Defines the technical specs that fulfill the PRD, but just as importantly, it’s where the tickets live and where I keep track of the project. Phased tickets (T-001 through T-00N), each with acceptance criteria, each marked todo / in progress / done as work moves. This file changes constantly.

The PRD is the why. The ERD is the how, plus where we are in delivering it. Together they’re the project’s memory and crucially, they’re the written form of the discovery conversation we already had, not a substitute for it.

Why the ERD is a living document

The trick that makes session handoff work is that the ERD updates as work is done. When T-005 ships, I (or Claude, on my prompt) check it off in the ERD and add any notes that future tickets will need, such as "uses the new RankingPolicy class added in T-005," "schema migrated, see commit abc123."

That means at any moment, the ERD answers three questions at once: how are we delivering the PRD, what’s done, and what’s next.

So when a session dies mid-feature, usage limit, accidental compaction, me rage-quitting because I’m tired or whatever may be. The next session doesn’t need a handoff prompt from me. It opens the ERD, sees what’s checked off and what isn’t, and picks up the next ticket.

What This Buys Me

A few things, all of them quiet but important:

• The hard thinking happens before there’s code to defend. In plan mode, no one’s invested in a half-built implementation. Changing your mind is free.
• Usage limits stop being expensive. They used to mean "lose twenty minutes re-briefing." Now they mean "open a new terminal, point at the ERD."
• Sub-agents brief themselves. When I spawn a review agent or a parallel implementer, I don’t write a context dump I tell it to read the PRD and the relevant ERD ticket. Same context every time.
• I can run two Claudes in parallel. One on T-004, one on T-006. Both inherit the same plan. The ERD coordinates them: whoever finishes first checks their ticket off, and the other sees the update next time it reads the file.
• Scope creep gets caught at the door. If a request doesn’t map to something in the PRD or ERD, that’s a flag either the plan needs to change deliberately, or the request shouldn’t happen.

A Typical Opening Sequence

Let’s take a simple TODO app as an example, the opening looked roughly like this:

1. Plan mode. I need to build a TODO app, we need to have session management, a user can share if they want, a task with another user. The system should notify users assigned/present on the tasks once it is close to the deadline or when it is past due. Once a task is marked as complete, there’s shouldn’t be any notification about it, a user can open/edit completed task or create copies of it. Use DDD lenses to help me find the gaps of this and discuss any other use case that I might be missing. We’re not building or choosing a tech stack, this is a conceptual step of what we’re building.

2. DDD discovery Q&A. Claude came back with questions like:

• "Is ‘assignee’ the same aggregate as ‘created by’ or is one a projection of the other?"
• "What’s the lifecycle of a task submission — created, todo, in progress, review, closed? Which transitions are valid?"

Half of those I answered in a sentence. A couple genuinely changed the design of what I was thinking, but that’s ok because we’re still planning, it won’t cost any refactoring to the code.

3. PRD. Once the questions stopped landing, I asked Claude to write the PRD reflecting what we’d just agreed on. I read it cold; if any sentence surprised me, that meant we hadn’t actually converged, and I sent it back.

4. ERD. "Given the PRD, draft the engineering spec: architecture choices, key components, and a phased ticket breakdown. Each ticket is atomic and shippable on its own, with explicit acceptance criteria. Mark every ticket [ ] for now." That gave me T-001 through T-008, sitting under a technical-specs section that explains how we’re delivering the PRD.

Only then does feature code get written. And every implementation session starts the same way.

What a Resumed Session Looks Like

Read docs/PRD.md and docs/ERD.md. Pick up the next unfinished ticket. Implement it using TDD. Commit atomically.
When the acceptance criteria of the ticket are met, mark it done in the ERD with any notes future tickets will need, then stop.

That’s the whole brief. No re-explaining. No "remember when we decided…" The ERD has the next ticket and the technical context around it. The PRD has the why. Claude has everything it needs in the working directory.

When the session ends, the ERD is already updated, because updating it is part of finishing the ticket. The next session opens with the same brief and finds itself one ticket further along.

My thoughts on experimenting with this flow

Claude is excellent at executing a well-specified ticket and mediocre at reconstructing a half-finished project from chat history. So I stop asking it to do the second thing.

Plan mode plus a DDD lens forces the ambiguities to the surface before any code exists to defend. The PRD and ERD then capture that conversation in a form that survives session boundaries. Together, they make every session resumable, every sub-agent briefable, and every parallel Claude usefully independent.

The planning isn’t overhead. It’s what makes long projects survive short sessions.

We want to work with you. Check out our Services page!