Idea to PRD
2 min read
Idea to PRD
Time required: 30–60 minutes (depends on idea complexity)
What this does: Turns a raw idea into a structured Idea Pack, then into a full PRD with numbered acceptance criteria.
When to use: Every time you start a new feature or product.
Important: Do this BEFORE any code is written. This is a non-negotiable.
What you will have after this: An approved Idea Pack, a detailed PRD with numbered acceptance criteria, and a testable checklist.
Step 1: Enter Plan Mode
Open Claude Code in your project folder:
cd ~/Documents/my-project-nameclaudePress Shift+Tab twice to enter Plan Mode. This puts Claude in read-only exploration mode — it will not write any code.
You should see a visual indicator that you are in Plan Mode.
Step 2: Create the Idea Pack
Paste this prompt into Claude Code. Replace the bracketed sections with your actual idea.
Create an Idea Pack document at /docs/idea/idea-pack.md with the following structure.I will give you my raw idea, and you will flesh it out into a complete Idea Pack.Ask me clarifying questions if my idea is unclear before writing the document.
My raw idea:
[DESCRIBE YOUR IDEA HERE IN PLAIN LANGUAGE. BE AS SPECIFIC OR VAGUE AS YOU WANT -- CLAUDE WILL ASK QUESTIONS TO FILL GAPS]
The Idea Pack must contain these sections:
1. **Problem Statement** -- What problem does this solve? Who has this problem? How painful is it?
2. **Proposed Solution** -- What are we building? One-paragraph summary.
3. **Target Users** -- Who specifically will use this? Be concrete (not "everyone").
4. **Core User Stories** -- List 5-10 user stories in the format: "As a [type of user], I want to [action] so that [benefit]"
5. **Out of Scope** -- What are we explicitly NOT building in this version? This is as important as what we ARE building.
6. **Success Metrics** -- How will we know this worked? List 3-5 measurable outcomes.
7. **Assumptions and Risks** -- What are we assuming? What could go wrong?
8. **Open Questions** -- What do we still need to figure out before building?
9. **Complexity Signal** -- Based on the scope above, provide an initial assessment: - Estimated number of distinct feature areas (e.g. auth, API, UI, data layer) - Are there natural boundaries where different parts could be built independently? - Flag any areas where multiple features share the same files or state -- these are coordination risks for parallel work later
10. **Discovery & SEO Strategy** -- (include if building a public-facing product where search discoverability matters; skip for internal tools, APIs, or early MVPs where SEO is not yet a priority) -- How will users find this? - What are the target keywords or search intents? - What content is public/crawlable vs. gated? - Are there technical SEO requirements (SSR, structured data, performance)? - What does the social sharing experience look like?
After creating the document, show me a summary and ask if anything needs to change.Make sure you spend as much time as you can on the description of your idea, the more detail you can provide the better.
Step 3: Review and iterate the Idea Pack
Read through what Claude produced. This is a human approval step. Ask yourself:
Does the problem statement match what I actually care about?
Are the user stories concrete enough that someone could build from them?
Is the "out of scope" list realistic?
Are there open questions that MUST be answered before we proceed?
Tell Claude what to change. Repeat until you are satisfied.
When you are happy, tell Claude:
The Idea Pack is approved. Commit this file.Step 4: Create the PRD
Now paste this prompt:
Read the approved Idea Pack at /docs/idea/idea-pack.md.Create a full Product Requirements Document at /docs/prd/prd.md.
The PRD must contain:
1. **Overview** -- One paragraph summary of what we are building and why.
2. **User Stories and Acceptance Criteria** -- Take every user story from the Idea Pack and expand it with numbered, testable acceptance criteria. Format:
US-001: As a [user], I want to [action] so that [benefit] - AC-001.1: Given [context], when [action], then [expected result] - AC-001.2: Given [context], when [action], then [expected result] - AC-001.3: (edge case) Given [context], when [action], then [expected result]
Every user story MUST have at least one happy-path AC and at least one edge-case/error AC.
3. **Functional Requirements** -- Detailed list of what the system must do, organised by feature area.
4. **Non-Functional Requirements** -- Performance targets, accessibility requirements, browser support, mobile responsiveness, security requirements.
5. **Data Model** -- What data entities exist? What are their relationships? What are the key fields?
6. **API Contracts** -- What endpoints exist? What do they accept and return? Be explicit about request/response shapes, status codes, and error formats. These contracts are the coordination layer that separate teammates will code against independently, so they must be precise enough that a frontend teammate and backend teammate can build to them without talking to each other.
7. **UI/UX Requirements** -- Key screens/pages, navigation flow, interaction patterns. This is setting up for the next step where UI/UX Pro Max will review all required pages to determine design system guidance, this includes designs for web/mobile app.
8. **Out of Scope** -- Copy from Idea Pack, expand if needed.
9. **Dependencies** -- What external services, APIs, or libraries will we need?
10. **Phased Delivery Plan** -- Break the build into 3-6 phases. Each phase should be independently testable. Phase 1 should be the minimum viable version.
For each phase, include: - Which user stories it delivers - Which feature areas it touches - Whether it can be parallelised with agent teams or must be sequential - Suggested team composition if parallelisable (e.g. "API + DB + Test teammates")
Format: - Phase 1: [description] -- delivers US-001, US-002 -- Sequential (foundational setup) - Phase 2: [description] -- delivers US-003, US-004 -- Parallelisable (API teammate + Frontend teammate + Test teammate) - etc.
After creating the PRD, create a separate file at /docs/prd/acceptance-checklist.mdthat extracts ALL acceptance criteria into a flat checklist:
- [ ] AC-001.1: [description]- [ ] AC-001.2: [description]- etc.
This checklist is what we will use to verify the build is complete.Step 5: Review and approve the PRD
This is another human approval step. Read through the entire PRD. Pay special attention to:
Are the acceptance criteria specific enough to test? Could you look at the running app and definitively say "yes this passes" or "no this fails"?
Is the phased delivery plan realistic? Is Phase 1 genuinely minimal?
Are the non-functional requirements explicit (not just "should be fast")?
Does the data model make sense?
Tell Claude what to change. Iterate until satisfied.
When approved:
The PRD is approved. Commit both the PRD and acceptance checklist.Checkpoint
Your project should now have:
/docs/idea/idea-pack.md — approved
/docs/prd/prd.md — approved
/docs/prd/acceptance-checklist.md — all items unchecked
Updated CLAUDE.md with project overview
Ready to make architecture decisions? Open Architecture and ADRs.
Sign up to read the full guide
Free access to all 12 workflow guides. No password needed.