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
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?
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:
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.
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:
- Order by dependency (foundation first, UI polish last)
- Tag with complexity estimates
- Identify which can be parallelized
- Start executing from Phase 4