Skip to content
Claude Code Guide

Phase 3: Product Plan with Stories

Now that you have a spec, turn it into executable work. This is where the spec becomes user stories, acceptance criteria, and a Definition of Done — structured so Claude Code can work through them methodically.


Linear + MCP for real visibility

I use Linear as my project tracker with the MCP server connected to Claude Code. This gives me:

  • Remote access — check progress from my phone via the Linear iOS app
  • Team visibility — stakeholders can see what's in progress without asking
  • Claude Code integration — Claude can read issues, update status, and create new tickets directly
Try this prompt
Based on our spec, break this project into user stories. For each story:

**Title:** [action-oriented, user-facing]
**As a** [user type], **I want** [capability] **so that** [benefit]

**Acceptance Criteria:**
- [ ] Specific, testable condition 1
- [ ] Specific, testable condition 2
- [ ] Specific, testable condition 3

**Definition of Done:**
- [ ] Unit tests pass
- [ ] Responsive at mobile + desktop breakpoints
- [ ] Accessibility: keyboard navigable, screen reader compatible
- [ ] No console errors or warnings

Order them by dependency — what needs to be built first?
Well-structured stories let Claude Code work through them sequentially with clear success criteria.

Structuring for multi-agent work

When using Claude Code's multi-agent orchestration (what I call "beads"), each story should be:

Self-contained. A single agent should be able to pick up the story and complete it without context from other in-progress work.

Testable in isolation. Each story has its own unit tests. If the story is complete, the tests pass — no dependencies on unfinished work.

Sized for one session. If a story takes more than ~30 minutes of Claude Code time, it's too big. Break it down further.

Complex flows: e2e workflow tests

For features that span multiple stories — like a full user onboarding flow or a multi-step data pipeline — write e2e workflow tests that validate the integrated behavior:

Try this prompt
Write an e2e test plan for the [workflow name] flow. This flow spans these stories:
1. [Story 1]
2. [Story 2]
3. [Story 3]

The test should validate the complete happy path and these critical edge cases:
- [Edge case 1]
- [Edge case 2]

Use Playwright for browser-based flows. Include assertions for both visible UI state and underlying data state.
E2e tests are the safety net that catches integration bugs between individually-passing stories.

Warning

Don't skip the Definition of Done. Without it, "done" becomes subjective. I've seen Claude Code declare a feature complete because the happy path works, while error states, loading states, and mobile layouts are completely broken. The DoD is your contract.

The story backlog becomes your execution plan

Once your stories are in Linear:

  1. Order by dependency (foundation first, UI polish last)
  2. Tag with complexity estimates
  3. Identify which can be parallelized
  4. Start executing from Phase 4

Next: The "Indispensable" Prompt →