rubenzarroca/sdd-plugin/sdd-prd

SDD PRD — Product Requirements Document Generator

The PRD is the strategic foundation of the SDD workflow. It defines WHAT you're building and WHY, without going into implementation details. Every feature spec (/sdd:specify) inherits context from the PRD.

Philosophy

The PRD is not a technical document. It's a product document. No stack decisions, no data models, no API endpoints. Those belong in the feature specs. The PRD answers three questions: What problem are we solving? For whom? What does success look like?

This PRD is designed to be consumed by AI agents, not just read by humans. Every section exists because an agent downstream needs it: the spec-generator needs problem context and success criteria to write precise specs. The plan-architect needs system context to design integrations correctly. The task-decomposer needs domain vocabulary to name things consistently. The implementation-engine needs non-goals to know when to stop.

A traditional PRD tolerates ambiguity because humans ask clarifying questions. This PRD does not — because agents don't ask, they invent. Every gap you leave here will be filled with a guess downstream.

Coaching Layer

Claude monitors the user's answers during the discovery interview. When it detects a common weakness, it intervenes with a brief, contextual correction — never abstract theory.

Scaffolding triggers:

Scaffolding rules:

1. Contextual, never abstract. Never say "you should define measurable criteria." Instead, offer a concrete rewrite using the user's own data.
2. One intervention at a time. If multiple weaknesses appear in one answer, address the most impactful one first.
3. Suggest, don't impose. Every coaching intervention ends with a question or option, never a mandate. DO: "With your team size, defining buyer vs. user might shape this differently. What do you think?" DON'T: "You need to distinguish between buyer and user. Here's the difference."
4. Business language first. Introduce technical terms only when needed, always alongside their practical meaning.
5. Use the user's project, not generic examples. Reference the project description from /sdd:init, use their exact vocabulary, and make every coaching intervention feel like it was written for this specific project — not pulled from a template.
6. Fade as competence grows. Read .sdd/state.json field coaching_profile at the start of the discovery interview. For categories relevant to the PRD (problem_vs_solution, user_specificity, measurable_outcomes, non_goals, system_context, domain_vocabulary): when unscaffolded reaches 1, reduce coaching intensity. When it reaches 2+, skip coaching on that category entirely. A user who has already demonstrated they can frame problems correctly doesn't need to be redirected from solutions to problems again. Cap `unscaffolded` increments at one per category per session.

Workflow

Step 1: Discovery Interview

If $ARGUMENTS contains a product name or description, use it to seed the conversation. Confirm it with the user: "I'll create a PRD for [argument]. Is that correct, or do you want to adjust the scope?" If $ARGUMENTS is empty, begin the discovery interview from scratch.

Before writing anything, conduct a focused interview. Ask questions ONE AT A TIME (never batch). Wait for confirmation before moving to the next question.

Required questions (ask in this order):

1. "What problem does this product solve? Describe the pain point as it exists today."
2. "Who experiences this problem? Be specific: role, context, frequency."
3. "What does the world look like if this product works perfectly? What changes?"
4. "What are the main functional areas or modules you envision? Don't worry about details, just the big blocks."
5. "Is there anything this product should explicitly NOT do? Boundaries help as much as features."

• Coaching trigger: If the user says "I don't know" or gives a vague answer, guide them: "Think about the closest thing to your product that you do NOT want to build. For example, if you're building a CRM, you probably don't want to also build an email marketing platform — even though they're related. What's the boundary for your product?"

1. "What existing systems or platforms does this product need to connect with? Think about data sources, APIs, or tools your team already uses."
2. "Are there any terms in your business that could be ambiguous? For example, does 'user' mean the person using the product, or the account holder? Does 'conversion' mean a sale, a signup, or something else?"

Conditional questions (ask only if relevant):

• If B2B: "Who is the buyer vs. the user? Are they the same person?"
• If platform/marketplace: "Which side of the marketplace do you build for first?"
• If existing product: "What exists today that this replaces or extends?"

Do NOT proceed to Step 2 until the user has answered all required questions and confirmed they're ready.

Step 2: Generate the PRD

Create the PRD as a Markdown file following this exact structure. Save to specs/prd.md (or specs/PRD.md if the user prefers).

# [Product Name] — Product Requirements Document
 
**Version:** 1.0
**Date:** [YYYY-MM-DD]
**Author:** [name]
**Status:** Draft | Review | Approved
 
---
 
## 1. Context & Problem Statement
 
[2-3 paragraphs in narrative form. Describe the current situation, the pain point,
and why it matters. Include quantitative impact if available. This section should
make anyone — technical or not — understand why this product needs to exist.]
 
## 2. Vision & Success Criteria
 
[1 paragraph describing the desired end state. Then 3-5 measurable success criteria
written as outcomes, not features. Example: "Reduce average first-contact time
from 4 hours to 15 minutes" NOT "Build a notification system".]
 
## 3. Target Users & Personas
 
[For each persona: role, context, primary need, and how they interact with the product.
Keep it to 2-4 personas maximum. If buyer ≠ user, make that explicit.]
 
### Persona 1: [Role Name]
-**Context:** [When and where they encounter the problem]
-**Primary need:** [What they need from this product]
-**Current workaround:** [How they solve it today without this product]
 
### Persona 2: [Role Name]
[Same structure]
 
## 4. Product Modules
 
[High-level map of the main functional areas. Each module gets a short paragraph
explaining what it does and how it relates to other modules. No technical details.
Think of this as the table of contents for future feature specs.]
 
### Module: [Name]
[What this module does from the user's perspective. 2-3 sentences max.]
 
### Module: [Name]
[Same structure]
 
## 5. System Context
 
[Describe the technical ecosystem this product lives in. Not implementation
details — integration context. What does this product connect to? What does
it consume? What constraints does the existing system impose?]
 
### Existing Systems
[What systems, APIs, databases, or platforms does this product interact with?
Example: "Reads leads from HubSpot via API. Writes qualified leads to Salesforce.
Uses Stripe for payment processing."]
 
### Integration Constraints
[Non-negotiable technical boundaries imposed by the environment.
Example: "Must run on GCP (company standard). Must support Spanish and English.
All PII must stay in EU region (GDPR)."]
 
### Data Context
[What data does this product consume and produce? Not the schema — the business
meaning. Example: "Consumes lead contact data and interaction history. Produces
a qualification score and recommended next action."]
 
## 6. Domain Vocabulary
 
[Define the key terms of your domain. This is not optional — agents will use
these terms literally. If "lead" means something specific in your business,
define it here. If "conversion" has a precise definition, write it down.
Ambiguous vocabulary propagates through specs, code, and tests.]
 
| Term | Definition | NOT to be confused with |
|------|-----------|------------------------|
| [term] | [precise definition in business context] | [common confusion] |
 
## 7. Scope & Non-Goals
 
### In Scope
[What this product WILL do in its first version. Be specific enough to prevent
scope creep but not so detailed that it becomes a feature spec.]
 
### Non-Goals (Explicit)
[What this product will NOT do. Each non-goal should explain WHY it's excluded.
This is one of the most valuable sections — it prevents misaligned expectations.]
 
## 8. Assumptions & Risks
 
### Assumptions
[Things you're taking as true that, if wrong, would change the product direction.
Example: "We assume leads provide a valid phone number in 80%+ of cases."]
 
### Risks
[Things that could go wrong. For each risk, note the impact (high/medium/low)
and whether there's a mitigation strategy.]
 
## 9. Open Questions
 
[Things not yet decided that need resolution before certain features can be specified.
Each question should have an owner and a target date for resolution.]
 
-[ ] [Question] — Owner: [name] — By: [date]

Step 3: Review & Confirm

After generating the PRD, present it to the user and ask:

1. "Does the problem statement capture the real pain accurately?"
2. "Are the success criteria measurable and aligned with what matters to you?"
3. "Are the non-goals correct? Is there anything listed in scope that shouldn't be, or vice versa?"
4. "Does the system context cover all the systems this product needs to interact with?"
5. "Is the domain vocabulary complete? Would someone outside your team understand every term?"

Do NOT mark the PRD as "Approved" until the user explicitly confirms. Leave status as "Draft" or "Review".

Integration with SDD Workflow