Replit PRD Generator

Create comprehensive Product Requirements Documents optimized for Replit Agent to build complex applications.

When to Use

Building complex applications with multiple features
Need stakeholder alignment before development
Want one-shot autonomous builds (entire app from single prompt)
Require clear acceptance criteria and testing plans
Working on team projects that need documentation

PRD vs Simple Prompt

Aspect	Simple Prompt	Full PRD
Features	1-3	4+
Pages/Screens	1-3	4+
User Roles	1	Multiple
Integrations	0-1	Multiple
Development Time	< 1 hour	Hours to days
Iterations Expected	Minimal	Multiple phases

Rule of thumb: If you can describe it in 10 lines, use a prompt. If you need structure, use a PRD.

PRD Template for Replit

markdown

# [Product Name] - Product Requirements Document

## 1. Executive Summary

### Product Name
[Name]

### Version
1.0.0

### Last Updated
[Date]

### One-Line Description
[What it is and who it's for in one sentence]

### Problem Statement
[What problem does this solve? Why does it matter?]

### Success Metrics
- [Metric 1: e.g., "User can complete core task in under 2 minutes"]
- [Metric 2: e.g., "Zero critical bugs in core user flows"]
- [Metric 3: e.g., "Page load time under 3 seconds"]

---

## 2. User Personas

### Persona 1: [Name/Role]
- **Description:** [Who they are]
- **Goals:** [What they want to achieve]
- **Pain Points:** [What frustrates them currently]
- **Tech Comfort:** [Low/Medium/High]

### Persona 2: [Name/Role]
- **Description:** [Who they are]
- **Goals:** [What they want to achieve]
- **Pain Points:** [What frustrates them currently]
- **Tech Comfort:** [Low/Medium/High]

---

## 3. Technical Specifications

### Tech Stack
| Layer | Technology | Rationale |
|-------|------------|-----------|
| Frontend | [Framework] | [Why chosen] |
| Styling | [Library] | [Why chosen] |
| Backend | [Framework] | [Why chosen] |
| Database | [System] | [Why chosen] |
| Auth | [Provider] | [Why chosen] |
| Hosting | Replit Deployments | Default |

### Architecture Overview

[Text diagram or description of system architecture]


### Third-Party Integrations
| Service | Purpose | API Type | Auth Method |
|---------|---------|----------|-------------|
| [Service] | [What for] | REST/GraphQL | API Key/OAuth |

### Environment Variables Required
| Variable | Description | Required |
|----------|-------------|----------|
| DATABASE_URL | PostgreSQL connection string | Yes |
| [VAR_NAME] | [Description] | Yes/No |

---

## 4. Data Model

### Entity: [EntityName]
| Field | Type | Required | Constraints | Description |
|-------|------|----------|-------------|-------------|
| id | UUID | Yes | Primary key | Unique identifier |
| [field] | [type] | Yes/No | [constraints] | [description] |

### Entity Relationships

User (1) ----< (many) Posts Post (1) ----< (many) Comments User (1) ----< (many) Comments


### Database Indexes
- [table].[column] - For [use case]
- [table].[column] - For [use case]

---

## 5. Feature Specifications

### Feature 1: [Feature Name]

#### Description
[What this feature does]

#### User Stories
- As a [role], I want to [action] so that [benefit]
- As a [role], I want to [action] so that [benefit]

#### Functional Requirements
| ID | Requirement | Priority |
|----|-------------|----------|
| F1.1 | [Specific requirement] | Must Have |
| F1.2 | [Specific requirement] | Must Have |
| F1.3 | [Specific requirement] | Nice to Have |

#### UI Components
- [Component 1]: [Description and behavior]
- [Component 2]: [Description and behavior]

#### API Endpoints
| Method | Endpoint | Request Body | Response | Auth |
|--------|----------|--------------|----------|------|
| POST | /api/[resource] | { field: type } | { field: type } | Required |
| GET | /api/[resource]/:id | - | { field: type } | Required |

#### Validation Rules
- [Field]: [Rule, e.g., "Email must be valid format"]
- [Field]: [Rule, e.g., "Password minimum 8 characters"]

#### Error Handling
| Error Condition | Error Code | User Message | System Action |
|-----------------|------------|--------------|---------------|
| [Condition] | 400/401/etc | [Friendly message] | [What happens] |

### Feature 2: [Feature Name]
[Repeat structure above]

---

## 6. UI/UX Specifications

### Design System
- **Primary Color:** [Hex code]
- **Secondary Color:** [Hex code]
- **Background:** [Hex code]
- **Text:** [Hex code]
- **Font Family:** [Font name]
- **Border Radius:** [Value, e.g., 8px]

### Page Layouts

#### Page: [Page Name]
- **Route:** /[path]
- **Layout:** [Description]
- **Components:**
  - [Component 1]
  - [Component 2]
- **State:** [What state this page manages]

### Navigation Structure

Home (/) ├── Dashboard (/dashboard) ├── [Section] (/[path]) │ ├── [Subsection] (/[path]/[subpath]) │ └── [Subsection] (/[path]/[subpath]) └── Settings (/settings)


### Responsive Breakpoints
| Breakpoint | Width | Layout Changes |
|------------|-------|----------------|
| Mobile | < 640px | [Changes] |
| Tablet | 640-1024px | [Changes] |
| Desktop | > 1024px | [Default layout] |

---

## 7. User Flows

### Flow 1: [Flow Name]

Start → [Step 1] → [Step 2] → [Decision Point] ├── Yes → [Step 3a] → End └── No → [Step 3b] → End


**Detailed Steps:**
1. User [action] on [page/component]
2. System [response/validation]
3. User sees [feedback/result]
4. [Continue...]

### Flow 2: [Flow Name]
[Repeat structure]

---

## 8. Non-Functional Requirements

### Performance
- Page load time: < [X] seconds
- API response time: < [X] ms
- Support [X] concurrent users

### Security
- [ ] Input sanitization on all forms
- [ ] HTTPS only
- [ ] SQL injection prevention (parameterized queries)
- [ ] XSS prevention
- [ ] CSRF tokens on forms
- [ ] Rate limiting on auth endpoints

### Accessibility
- [ ] Keyboard navigable
- [ ] Screen reader compatible
- [ ] Color contrast ratio 4.5:1 minimum
- [ ] Focus indicators visible

### Browser Support
- Chrome (latest 2 versions)
- Firefox (latest 2 versions)
- Safari (latest 2 versions)
- Edge (latest 2 versions)

---

## 9. Scope Boundaries

### In Scope (MVP)
- [Feature/capability 1]
- [Feature/capability 2]
- [Feature/capability 3]

### Out of Scope (Future)
- [Feature/capability 1] - Reason: [why deferred]
- [Feature/capability 2] - Reason: [why deferred]

### Explicit Non-Goals
- [Thing this product will NOT do]
- [Thing this product will NOT do]

---

## 10. Acceptance Criteria

### Feature 1: [Name]
- [ ] [Testable criterion 1]
- [ ] [Testable criterion 2]
- [ ] [Testable criterion 3]

### Feature 2: [Name]
- [ ] [Testable criterion 1]
- [ ] [Testable criterion 2]

### Overall Application
- [ ] All pages load without errors
- [ ] All forms validate correctly
- [ ] All API endpoints return expected responses
- [ ] Mobile layout is functional
- [ ] No console errors in production

---

## 11. Development Phases

### Phase 1: Foundation (Checkpoint 1)
**Goal:** Basic structure and auth
- [ ] Project setup with tech stack
- [ ] Database schema and migrations
- [ ] Authentication flow
- [ ] Basic navigation/layout

### Phase 2: Core Features (Checkpoint 2)
**Goal:** Primary functionality
- [ ] [Core feature 1]
- [ ] [Core feature 2]

### Phase 3: Polish (Checkpoint 3)
**Goal:** UX and edge cases
- [ ] Error handling
- [ ] Loading states
- [ ] Responsive design
- [ ] Form validations

### Phase 4: Launch (Checkpoint 4)
**Goal:** Production ready
- [ ] Final testing
- [ ] Performance optimization
- [ ] Security review
- [ ] Documentation

---

## 12. Risks and Mitigations

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| [Risk 1] | High/Med/Low | High/Med/Low | [How to address] |
| [Risk 2] | High/Med/Low | High/Med/Low | [How to address] |

---

## 13. Appendix

### Wireframes/Mockups
[Links or embedded images]

### Reference Applications
- [App name](URL) - Similar [feature/design]
- [App name](URL) - Similar [feature/design]

### API Documentation Links
- [Service]: [URL]

### Glossary
| Term | Definition |
|------|------------|
| [Term] | [Definition] |

Procedure

Step 1: Gather High-Level Requirements

Ask the user:

What is the product and who is it for?
What are the 3-5 most important features?
Any specific tech requirements or preferences?
Any reference apps or designs to emulate?

Step 2: Define User Personas

For each user type:

Who are they?
What do they need to accomplish?
What's their technical skill level?

Step 3: Detail Features

For each feature, extract:

User stories
UI components needed
Data required
API endpoints
Validation rules
Error scenarios

Step 4: Design Data Model

List all entities
Define all fields with types and constraints
Map relationships
Identify required indexes

Step 5: Specify UI/UX

Color palette
Page layouts
Navigation structure
Responsive behavior
Key interactions

Step 6: Define User Flows

Document step-by-step:

Happy path
Error paths
Edge cases

Step 7: Set Acceptance Criteria

Create testable checkboxes for:

Each feature
Overall functionality
Performance requirements

Step 8: Plan Development Phases

Break into 3-4 phases with:

Clear goals
Specific deliverables
Checkpoint criteria

Step 9: Present Draft PRD

## PRD Draft: [Product Name]

**Complexity:** [Low/Medium/High]
**Estimated Phases:** [Number]
**Primary Persona:** [Name]

---

[Full PRD content]

---

## Usage Instructions

1. Copy entire PRD to Replit Agent
2. Use Plan Mode first to review Agent's approach
3. Approve plan and start Phase 1
4. Create checkpoint after each phase
5. Review and iterate before next phase

Ready to proceed?

Step 10: Provide Iteration Guidance

After PRD delivery:

How to use Plan Mode effectively
When to create checkpoints
How to handle deviations

Output Format

# [Product Name] PRD

## Quick Reference

| Attribute | Value |
|-----------|-------|
| Complexity | [Low/Medium/High] |
| Features | [Count] |
| Pages | [Count] |
| API Endpoints | [Count] |
| Phases | [Count] |

---

[Full PRD following template]

---

## Replit Agent Instructions

**Mode:** Start in Plan Mode

**Phase 1 Prompt:**
"Review this PRD and create a development plan for Phase 1: [Phase 1 Goal].
Don't start building yet - just outline your approach."

**Build Prompt (after plan approval):**
"Proceed with Phase 1 implementation. Create a checkpoint when complete."

**Subsequent Phases:**
Repeat plan → build → checkpoint cycle for each phase.

Rules

ALWAYS include acceptance criteria — Every feature needs testable conditions
ALWAYS define data model — Schema before code
ALWAYS specify error handling — Every feature's error scenarios
ALWAYS break into phases — 3-4 phases with clear checkpoints
NEVER leave fields vague — Every input has type, constraints, validation
NEVER skip security requirements — Always include security section
PREFER reference apps — Concrete examples over abstract descriptions

Additional Resources

See reference files:

references/prd-examples.md
— Complete PRD examples for different app types

replit-prd

NPX Install

Tags

SKILL.md Content