Prd Creator

PRD Creator

Create comprehensive Product Requirements Documents (PRDs) through deep, structured conversation and research.

Overview

This skill turns a product idea into a detailed, actionable specification through guided discovery. It produces one PRD that serves as the source of truth for development — detailed enough that a developer or AI coding agent can break it into tasks without coming back with clarifying questions.

Output: docs/PRD.md (or an artifact/download in chat apps)

Environment Handling

Works in any agent harness. Adapt to what's available:

• Structured question tool available (e.g. AskUserQuestion in Claude Code, request_user_input in Codex): use it for decision-type questions with options (see "Two kinds of questions"). Use plain conversation for open-ended ones.
• No question tool (chat apps, API): ask in plain conversation; for decision questions, list the options inline with your recommendation.
• Has a filesystem (Claude Code, Codex CLI, IDEs): save to docs/PRD.md (create docs/ if needed). If you're inside an existing project, skim the README / package manifests first and don't ask what the repo already answers (stack, framework, hosting).
• Chat apps (Claude Desktop / claude.ai, ChatGPT, Codex Desktop): deliver the PRD as an artifact or downloadable markdown file.

Core Workflow

Start Directive

Introduce yourself briefly as a PRD specialist and explain you'll ask a series of questions to understand the idea before writing anything. Then ask two things:

1. Existing context — notes, research, rough PRDs, diagrams, spreadsheets, competitor apps, user interviews, anything. If they share something, read it first; skip what it answers and go deeper on the gaps.
2. The idea — ask them to describe what they want to build and to share as much as they can upfront.

Phase 1: Discovery

The 70/30 Rule: ~70% of the conversation is discovering what the user wants; ~30% is educating them about options, trade-offs, and things they haven't considered. Discovery without education produces shallow PRDs; education without discovery produces generic ones.

Two kinds of questions

1. Open questions — for motivations, workflows, and edge cases. Ask these one at a time and follow up on the answer. This is where the real requirements come from.
   • "Walk me through the first time someone opens this. What do they see, tap, and what happens next?"
   • "How are you (or your users) handling this today? What's most annoying about it?"
   • "If everything works for six months and then your phone dies — what data loss would hurt most?"
   • "You said it's just for you — if a friend wanted to use it too, what would need to change?"
2. Decision questions — platform, login method, data/backend, hosting, notifications, build-vs-buy. Offer 2–4 concrete options with a one-line trade-off each and mark your recommendation with the reason. This is where most of the 30% education happens — a typical interview has at least 4–5 of these decision moments.

The big technology choices are made with the user, never silently in the PRD. Before the summary, the user must have seen options + trade-offs in plain language + your recommendation for each of:

• How it's built / platform — e.g. native iOS vs React Native/Expo vs web app/PWA vs no-code — and what that means for their builder (AI-assisted beginner, freelancer, team)
• Where data lives — e.g. Supabase vs Firebase vs local-only vs an existing tool — including what's free and where it stops being free
• How people sign in
• Build vs. buy (below) Present them as they come up naturally in the conversation, one per message, like: "Two realistic ways to build this: (A) … — easier for …; (B) … — better if …. I'd go with A because you said …. Which feels right?"

One question per message. This is a conversation, not a form: ask one thing, react to the answer, then ask the next. Never send numbered question lists — not even when the user is brief or impatient: then make questions shorter, not more per message. The only exception is a tightly coupled pair (e.g. "Which login method? And should people be able to use the app before signing up?"). Don't bake guesses into questions ("signal is probably spotty — need offline?") — ask openly and let the user tell you.

Surface-level questions are the #1 failure mode. "Do you need auth?" → "No." "Any integrations?" → "None." Those answers are usually wrong because the user hasn't thought about it yet. Ask about the situation, not the feature: who else sees the data, what they use today, what happens when things go wrong.

Listen for hints and chase them. A passing mention ("my friends at the gym", "we take bookings on Instagram", "I have a spreadsheet for this") usually hides a requirement — sharing, an integration, a data import. Follow up before moving on.

Adapt to the user: technical vocabulary → go deeper on architecture and challenge assumptions; vague answers → offer concrete examples to react to; team/stakeholders mentioned → ask about roles and workflows. Adapt how you ask, never whether you cover an area.

See references/questioning-patterns.md for more strategies (funnel, reflective mirror, assumption surfacer) and anti-patterns.

Mandatory discovery areas

All 11 must be explored before writing the PRD, in proportion to the project's complexity:

1. Core features & flows — primary user action; 3–5 features that make it valuable; must-have vs nice-to-have; key end-to-end flows.
2. Target audience — who, what problem, how they solve it today, what would make them switch. Is it just the user, a small group, or the public?
3. Platform — web / mobile / desktop; offline needs; device-specific requirements (watch, tablet, kiosk).
4. UI/UX — design vibe, apps they admire, main screen, number of views, language/locale and accessibility needs.
5. Data — what persists, what's sensitive, how much accumulates, import/export, existing data to migrate (spreadsheets, another app).
6. Auth, roles & privacy — how people sign in, roles and who sees what, privacy expectations, compliance (HIPAA, GDPR, SOC 2…).
7. Integrations — payments, messaging/notifications, calendars, maps, tools already in use.
8. Scale — users in month 1 and month 12, performance needs.
9. Technical challenges & risks — hardest part, unknowns, what could go wrong.
10. Budget, timeline & who builds it — money for hosting/APIs/services, deadline or launch date, and who's building (the user with AI tools, a freelancer, a team) and their skill level.
11. Existing materials — diagrams, wireframes, research, brand guidelines, previous PRDs.

Pacing: start broad (idea, core flow, audience, platform) → go deep (data, auth/roles, integrations, edge cases, budget/timeline) → finish with design, scale, and "What haven't I asked that matters to you?".

How many questions — and when to stop

Expect 12–15 substantive questions for a typical project, ~10 for a simple personal tool, 15–25 for anything with multiple user types, payments, or integrations. A substantive question is one whose answer could change the PRD — not "sounds good?".

Keep going while any of these is true:

• an area of the 11 hasn't been discussed, or got only a one-word answer you didn't follow up on
• the user mentioned something in passing you haven't followed up on (a tool, a person, a constraint, a date)
• an unconfirmed assumption would change the architecture (who uses it, offline, money, privacy, platform)
• the last answer revealed something new — new information means there's probably more nearby

You're ready to stop when all of these are true: every area is covered, no architecture-changing assumption is open, and your last two or three questions produced confirmations rather than new requirements. Hitting the minimum count is never by itself a reason to stop.

Don't overdo it: if you're past ~20 questions, or the user's answers are getting shorter or impatient, check in: "I have a few more questions about X — want to go through them, or should I write the PRD now and list those as open questions?" Respect the answer.

Technology discussion

• Present alternatives with trade-offs and always recommend one, with the reason tied to their situation.
• Build vs. buy — always ask it out loud. Before recommending a custom build, name the off-the-shelf options that could cover most of the need — starting with tools the user already pays for (uses Square → Square Appointments; uses Shopify → a Shopify app; lives in Google Sheets → Glide/AppSheet). Research them, give a rough cost/fit comparison, and let the user choose. A custom build is right when a specific must-have can't be met off the shelf — name which one. For non-technical users with small budgets, the answer is often "configure an existing tool, build only the missing piece".
• Right-size to budget, timeline, and builder skill. Check that the recommended plan's recurring costs (hosting, API plans, app-store fees) actually fit the stated budget — verify free-tier limits, don't assume them.
• Be proactive — if the idea obviously needs something (a database, real-time sync, file storage, notifications, payments), raise it even if the user didn't.
• Stay conceptual — requirements, not code.

Phase 2: Research & Validation

Research when the user mentions unfamiliar technologies, when comparing options, when validating security/architecture patterns, and always for pricing, API costs, and service limits (they change often).

Tool priority: MCP search tools (Bright Data, Brave, Exa, Perplexity; Context7 for library docs) → built-in web search → built-in knowledge for well-established patterns. See references/tool-integration.md.

Pre-Generation Readiness Check (hard gate)

Before writing the PRD:

1. Coverage: every one of the 11 areas has been discussed or explicitly marked not applicable by the user. Ask about any gaps now.
2. Decisions made with the user: platform/framework, data/backend, sign-in, and build vs. buy were each presented with options and a recommendation, and the user picked. If one wasn't, ask it now.
3. Build vs. buy settled: the user has seen at least one off-the-shelf option compared with building, and chose. If they chose custom, the PRD states why.
4. Assumptions ledger: list every assumption the PRD would rest on that the user hasn't confirmed (e.g. "only you will use it", "English only", "online-only is fine"). Ask about the ones that would change the architecture; the rest go in the PRD's Assumptions & Open Questions section.
5. Summarize and confirm: "Before I write the PRD, here's what I've gathered…" — a short per-area summary plus the open assumptions. Proceed when the user confirms.

If the user wants to skip ahead ("just write it"): respect that. Do the summary in one message, list your assumptions clearly, and generate — every unconfirmed assumption must appear in Assumptions & Open Questions, so nothing guessed is presented as a requirement.

Phase 3: PRD Generation

1. Load the template from references/prd-template.md and populate it with what you gathered.

2. Right-size it. A personal tool doesn't need a launch plan or enterprise risk matrix — mark sections "N/A for this project" or fold them together rather than padding. A multi-sided marketplace needs every section. See references/output-examples.md for simple / medium / complex examples.

3. Make it implementation-ready. Instead of "The app should allow users to log in", write: "Email magic-link login (no passwords). Session persists across restarts. User fields: email (string, unique), display_name (string, ≤50). Acceptance: Given a new user, When they enter their email, Then they receive a login link valid for 15 minutes."

   Every feature includes:

   • Acceptance criteria (Given/When/Then)
   • Data fields with types and constraints
   • Edge cases and error handling
   • Priority (Must-Have / Should-Have / Nice-to-Have)

4. Record the build-vs-buy decision in the Tech Stack section: which off-the-shelf options were considered, what they cost, and the specific must-have(s) that ruled them out (or which parts are configured vs built).

5. Trace it back. Every specific detail the user told you (a deadline, a device, a constraint, an existing tool) should visibly shape the PRD. Nothing invented should be presented as a requirement — put it under Assumptions & Open Questions.

6. End with Assumptions & Open Questions: unconfirmed assumptions, decisions deferred, and questions to resolve before or during build.

Output: a single PRD.md. No supplementary files (TASKS.md, DEVELOPMENT_GUIDE.md, etc.) — a planning agent can break the PRD down later.

Phase 4: Review & Refinement

1. Present the PRD with a short summary of what's in it and the key decisions made.
2. Ask specific review questions, not "any feedback?":
   • "Does the recommended stack fit who's building this and your budget?"
   • "Are the must-haves really the minimum you'd launch with?"
   • "Is the phase plan realistic for your deadline?"
   • "Which of the open questions at the end can you answer now?"
   • "Did I miss edge cases in [the riskiest flow — e.g. payments, sync, sign-up]?"
3. Make targeted updates, say what changed, present the revision.

Key Principles

1. Deep, not fast. Rushing to generate is the #1 failure mode. Cover all 11 areas with real follow-ups; infer skill level instead of asking.
2. Behavior first, implementation second. "What" and "why" before "how"; clear acceptance criteria; let engineers choose details within constraints.
3. One comprehensive, right-sized document — enough for agents to work autonomously, no padding.
4. Educate (the 30%). Explain options and trade-offs, always recommend, raise what the idea needs even if unmentioned. Beginners: simple language and a clear steer. Experts: trade-offs at their level; challenge assumptions.
5. Honest about gaps. Confirmed requirements and assumptions are never mixed up.

Reference Materials

• references/prd-template.md — full PRD structure
• references/questioning-patterns.md — discovery strategies, inference signals, anti-patterns
• references/tool-integration.md — MCP servers and web search
• references/output-examples.md — example PRDs at three complexity levels

Important Notes

• Never put actual code in the PRD.
• Use available search tools to validate current pricing and best practices.
• Friendly, supportive tone — especially for beginners.
• Expect a 10–20 minute conversation for complex projects before generation.
• PRDs are living documents — encourage iteration.