PRD & Spec Writing

I have a product idea I need to turn into a proper PRD. Here's the rough concept:

${roughIdea}

Write a PRD with these sections:

**1. PROBLEM STATEMENT** (2-3 sentences)
What problem does this solve? Who has this problem? Why does it matter now?

**2. TARGET USER**
- Primary persona: Who uses this feature directly?
- Secondary persona: Who benefits indirectly?
- Who is this NOT for?

**3. SUCCESS METRICS**
3-5 measurable outcomes that tell us this feature worked. Be specific — "increased engagement" is not a metric. "DAU of feature > 500 within 30 days of launch" is.

**4. USER STORIES**
Write 5-8 user stories in the format:
"As a [persona], I want to [action] so that [outcome]."
Prioritize: Must-have vs Nice-to-have

**5. FUNCTIONAL REQUIREMENTS**
Detailed list of what the system must do. Be specific enough that an engineer could estimate the work:
- Input/output behavior
- Edge cases
- Error states
- Permissions/access control

**6. NON-FUNCTIONAL REQUIREMENTS**
- Performance expectations (response time, throughput)
- Scale requirements (how many users, how much data)
- Security/privacy considerations
- Accessibility requirements

**7. OUT OF SCOPE**
Explicitly list what this feature does NOT include. This prevents scope creep.

**8. OPEN QUESTIONS**
List 3-5 things that still need to be decided before engineering starts. Flag these clearly.

**9. DEPENDENCIES**
What else needs to exist or change for this feature to work?

Keep the total PRD under 3 pages. Dense and specific beats long and vague.

Looking at the PRD we just wrote, help me scope the MVP:

1. Which user stories are truly must-have for the first version?
2. Which requirements can be hardcoded or simplified for v1? (e.g., "support 3 preset templates instead of custom templates")
3. What's the simplest implementation that would let us validate whether users actually want this?
4. What can we defer to v2 without undermining the core value proposition?

I want to ship something users can try in ${timeline}. What's realistic?

Review this PRD and identify edge cases I haven't considered:

${prdContent}

For each edge case:
| Edge Case | What Happens | Recommended Behavior | Priority |

Focus on:
- Empty states (no data, no users, no permissions)
- Scale limits (what if there are 100,000 items?)
- Concurrency (what if two users edit the same thing?)
- Permissions (what if a user's access changes while they're in a flow?)
- Data integrity (what if the source data is malformed, missing fields, or duplicated?)
- Error recovery (what happens when an external API fails mid-operation?)
- Timezone handling (if dates/times are involved)

Don't list every possible edge case — focus on the ones most likely to bite us in production.

Save this as project instructions for all product work:

PRODUCT: ${productName}
DESCRIPTION: ${productDescription}

ARCHITECTURE:
- ${architectureNotes}

USERS:
- ${userTypes}

EXISTING FEATURES:
- ${featureList}

TECH STACK:
- ${techStack}

DESIGN SYSTEM:
- ${designSystem}

CONVENTIONS:
- Feature flags for all new features
- All new endpoints require authentication
- All user-facing text must support internationalization
- ${conventions}

When I ask you to write a PRD, always:
1. Check if the feature overlaps with or depends on existing features
2. Use our established patterns (not novel architecture)
3. Include feature flag spec
4. Consider impact on existing users (migration, breaking changes)
5. Flag anything that requires infrastructure changes

Convert this PRD into a technical specification:

${prdContent}

TECHNICAL SPEC FORMAT:

**1. SYSTEM DESIGN**
- High-level architecture diagram (describe it in text)
- New components/services needed
- Changes to existing components

**2. DATA MODEL**
- New tables/collections with field definitions, types, constraints
- Changes to existing tables
- Migration strategy (if modifying existing data)

**3. API DESIGN**
For each new endpoint:
- Method and path
- Request body (with types)
- Response body (with types)
- Authentication/authorization
- Rate limiting
- Error responses

**4. BUSINESS LOGIC**
Pseudocode or detailed description of core logic:
- Input validation rules
- Processing steps
- State transitions
- Side effects (emails, notifications, webhooks)

**5. TESTING STRATEGY**
- Unit tests: what to test
- Integration tests: critical paths
- Edge cases from the PRD mapped to specific test cases

**6. ROLLOUT PLAN**
- Feature flag strategy
- Migration steps
- Rollback plan
- Monitoring/alerting to add

**7. ESTIMATED EFFORT**
Break down by component:
| Component | Estimate | Dependencies | Risk |

I have a detailed PRD. Write three versions for different audiences:

**VERSION 1: ENGINEERING** (already have the full PRD — this is a kickoff summary)
- 5 bullet points covering: what we're building, why, key technical decisions, timeline, first milestone
- Under 200 words

**VERSION 2: EXECUTIVE TEAM**
- 3-4 sentences: what it does, why it matters, expected impact on [metric], target ship date
- No technical details
- Under 100 words

**VERSION 3: CUSTOMER-FACING** (for changelog/announcement)
- What's new and why they should care
- How to use it
- What's coming next
- Under 150 words, friendly tone

The PRD:
${prdContent}