PRD Generator

Create detailed Product Requirements Documents that are clear, actionable, and suitable for autonomous AI implementation via the Ralph loop.

The Job

1. Receive a feature description from the user
2. Ask 3-5 essential clarifying questions (with lettered options)
3. Generate a structured PRD based on answers
4. Save to PRD.md
5. Create empty progress.txt

Important: Do NOT start implementing. Just create the PRD.

Step 1: Clarifying Questions

Ask only critical questions where the initial prompt is ambiguous. Focus on:

• Problem/Goal: What problem does this solve?
• Core Functionality: What are the key actions?
• Scope/Boundaries: What should it NOT do?
• Success Criteria: How do we know it's done?

Format Questions Like This:

1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI

This lets users respond with "1A, 2C, 3B" for quick iteration.

Step 2: Story Sizing (THE NUMBER ONE RULE)

Each story must be completable in ONE context window (~10 min of AI work).

Ralph spawns a fresh instance per iteration with no memory of previous work. If a story is too big, the AI runs out of context before finishing and produces broken code.

Right-sized stories:

• Add a database column and migration
• Add a single UI component to an existing page
• Update a server action with new logic
• Add a filter dropdown to a list

Too big (MUST split):

Rule of thumb: If you cannot describe the change in 2-3 sentences, it is too big.

Step 3: Story Ordering (Dependencies First)

Stories execute in priority order. Earlier stories must NOT depend on later ones.

Correct order:

1. Schema/database changes (migrations)
2. Server actions / backend logic
3. UI components that use the backend
4. Dashboard/summary views that aggregate data

Wrong order:

US-001: UI component (depends on schema that doesn't exist yet!)
US-002: Schema change

Step 4: Acceptance Criteria (Must Be Verifiable)

Each criterion must be something Ralph can CHECK, not something vague.

Good criteria (verifiable):

• "Add status column to tasks table with default 'pending'"
• "Filter dropdown has options: All, Active, Completed"
• "Clicking delete shows confirmation dialog"
• "Typecheck passes"
• "Tests pass"

Bad criteria (vague):

• "Works correctly"
• "User can do X easily"
• "Good UX"
• "Handles edge cases"

Always include as final criterion:

"Typecheck passes"

For stories that change UI, also include:

"Verify changes work in browser"

PRD Structure

Generate the PRD with these sections:

1. Introduction

Brief description of the feature and the problem it solves.

2. Goals

Specific, measurable objectives (bullet list).

3. User Stories

Each story needs:

• ID: Sequential (US-001, US-002, etc.)
• Title: Short descriptive name
• Description: "As a [user], I want [feature] so that [benefit]"
• Acceptance Criteria: Verifiable checklist

Format:

markdown
1### US-001: [Title]
2**Description:** As a [user], I want [feature] so that [benefit].
3
4**Acceptance Criteria:**
5- [ ] Specific verifiable criterion
6- [ ] Another criterion
7- [ ] Typecheck passes
8- [ ] [UI stories] Verify changes work in browser

4. Non-Goals

What this feature will NOT include. Critical for scope.

5. Technical Considerations (Optional)

• Known constraints
• Existing components to reuse

Example PRD

markdown
1# PRD: Task Priority System
2
3## Introduction
4
5Add priority levels to tasks so users can focus on what matters most. Tasks can be marked as high, medium, or low priority, with visual indicators and filtering.
6
7## Goals
8
9- Allow assigning priority (high/medium/low) to any task
10- Provide clear visual differentiation between priority levels
11- Enable filtering by priority
12- Default new tasks to medium priority
13
14## User Stories
15
16### US-001: Add priority field to database
17**Description:** As a developer, I need to store task priority so it persists across sessions.
18
19**Acceptance Criteria:**
20- [ ] Add priority column: 'high' | 'medium' | 'low' (default 'medium')
21- [ ] Generate and run migration successfully
22- [ ] Typecheck passes
23
24### US-002: Display priority indicator on task cards
25**Description:** As a user, I want to see task priority at a glance so I know what needs attention first.
26
27**Acceptance Criteria:**
28- [ ] Each task card shows colored priority badge (red=high, yellow=medium, gray=low)
29- [ ] Priority visible without hovering or clicking
30- [ ] Typecheck passes
31- [ ] Verify changes work in browser
32
33### US-003: Add priority selector to task edit
34**Description:** As a user, I want to change a task's priority when editing it.
35
36**Acceptance Criteria:**
37- [ ] Priority dropdown in task edit modal
38- [ ] Shows current priority as selected
39- [ ] Saves immediately on selection change
40- [ ] Typecheck passes
41- [ ] Verify changes work in browser
42
43### US-004: Filter tasks by priority
44**Description:** As a user, I want to filter the task list to see only high-priority items when I'm focused.
45
46**Acceptance Criteria:**
47- [ ] Filter dropdown with options: All | High | Medium | Low
48- [ ] Filter persists in URL params
49- [ ] Empty state message when no tasks match filter
50- [ ] Typecheck passes
51- [ ] Verify changes work in browser
52
53## Non-Goals
54
55- No priority-based notifications or reminders
56- No automatic priority assignment based on due date
57- No priority inheritance for subtasks
58
59## Technical Considerations
60
61- Reuse existing badge component with color variants
62- Filter state managed via URL search params

Output

Save to PRD.md in the current directory.

Also create progress.txt:

markdown
1# Progress Log
2
3## Learnings
4(Patterns discovered during implementation)
5
6---

Checklist Before Saving

• Asked clarifying questions with lettered options
• Incorporated user's answers
• User stories use US-001 format
• Each story completable in ONE iteration (small enough)
• Stories ordered by dependency (schema → backend → frontend)
• All criteria are verifiable (not vague)
• Every story has "Typecheck passes" as criterion
• UI stories have "Verify changes work in browser"
• Non-goals section defines clear boundaries
• Saved PRD.md and progress.txt