PRP Generator

What this skill does

# PRP Generator (Product Requirements Prompt)

## Overview

The PRP Generator helps you create comprehensive Product Requirements Prompts - structured documents that capture everything needed to build a product feature or system. PRPs are optimized for AI-assisted development, providing clear requirements that both humans and AI can understand.

**Core Purpose:** Transform vague ideas into actionable, complete requirements.

## When to Use This Skill

Use PRP Generator when:

- Starting a new product or major feature
- Requirements are unclear or scattered
- Need to communicate requirements to development team
- Using AI assistants for implementation
- Transitioning from discovery to development
- Onboarding new team members to a project

## Key Capabilities

- Structure requirements into 12 standardized sections
- Identify project complexity pattern (A, B, C)
- Extract user stories in Jobs-to-be-Done format
- Define success criteria and metrics
- Document functional and non-functional requirements
- Capture constraints, risks, and assumptions
- Clarify what's in and out of scope

## Workflow

### The 12-Section PRP Structure

A complete PRP contains these 12 sections:

1. **Project Overview**
2. **Problem Statement**
3. **Success Criteria**
4. **User Stories (Jobs-to-be-Done)**
5. **Functional Requirements**
6. **Non-Functional Requirements**
7. **Technical Constraints**
8. **Data Requirements**
9. **UI/UX Requirements**
10. **Risks & Assumptions**
11. **Out of Scope**
12. **Open Questions**

Let's dive into each:

---

### 1. Project Overview

**Purpose:** High-level context and pattern classification

**What to Include:**

- Project name and one-sentence description
- Pattern classification (A, B, or C)
- Timeline estimate
- Target users
- Business context

**Example:**

```
Project: Customer Support Chatbot
Pattern: C (AI-Native System)
Timeline: 10-12 weeks
Users: Customer support agents + end customers
Context: Reduce support ticket volume by 40% while maintaining customer satisfaction
```

---

### 2. Problem Statement

**Purpose:** Clearly define the problem being solved

**Template:**

```
[User type] faces [problem] when [situation].
This causes [negative outcome].
We know this because [evidence].
```

**Example:**

```
Customer support agents face long response times when customers ask common questions about billing, account setup, and feature usage. This causes customer frustration and agent burnout handling repetitive inquiries.

We know this because:
- 60% of tickets are "How do I..." questions
- Average response time is 4 hours
- Agent surveys show 70% of time spent on repetitive questions
- NPS dropped from 45 to 38 in past 6 months
```

---

### 3. Success Criteria

**Purpose:** Define measurable outcomes

**Structure:**

- Primary metric (North Star)
- Secondary metrics
- Minimum success thresholds

**Example:**

```
Primary Metric:
- Reduce support ticket volume by 40% within 3 months of launch

Secondary Metrics:
- 80% of common questions answered by AI without escalation
- <2 second response time for AI answers
- >4.0/5.0 user satisfaction rating with AI responses
- 50% reduction in agent time spent on common questions

Minimum Success:
- 30% ticket reduction + 4.0/5.0 satisfaction
```

---

### 4. User Stories (Jobs-to-be-Done)

**Purpose:** Capture user needs in job-to-be-done format

**Template:**

```
When [situation], I want to [action], so I can [outcome].
```

**Example:**

```
Customer Stories:
1. When I have a billing question, I want instant answers, so I can resolve issues without waiting.
2. When I'm setting up my account, I want step-by-step guidance, so I don't get stuck.
3. When I need to reset my password, I want a simple self-service flow, so I don't need to contact support.

Agent Stories:
1. When a complex issue arrives, I want context from the AI conversation, so I can help efficiently.
2. When training new agents, I want the AI to handle basics, so I can focus on teaching advanced topics.
3. When customers escalate, I want conversation history, so I don't ask redundant questions.
```

---

### 5. Functional Requirements

**Purpose:** What the system must do

**Categories:**

- Core features (P0 - must have)
- Important features (P1 - should have)
- Nice-to-have (P2 - could have)

**Example:**

```
P0 (Core - MVP):
- FR-001: System answers common questions from knowledge base
- FR-002: System escalates to human when confidence is low (<70%)
- FR-003: Agents can see full conversation history
- FR-004: System tracks conversation satisfaction ratings

P1 (Important - Post-MVP):
- FR-005: System learns from agent corrections
- FR-006: System handles multi-turn conversations with context
- FR-007: Agents can override AI suggestions

P2 (Nice-to-have - Future):
- FR-008: System proactively suggests help articles
- FR-009: System detects frustrated customers
- FR-010: Multi-language support
```

---

### 6. Non-Functional Requirements

**Purpose:** How the system should perform

**Categories:**

- Performance
- Security
- Scalability
- Reliability
- Usability

**Example:**

```
Performance:
- NFR-001: Response time <2 seconds for 95th percentile
- NFR-002: Handle 100 concurrent conversations
- NFR-003: Knowledge base search <500ms

Security:
- NFR-004: Customer data encrypted at rest and in transit
- NFR-005: SOC2 Type II compliance
- NFR-006: Role-based access control (RBAC)
- NFR-007: Audit logs for all AI responses

Scalability:
- NFR-008: Support 10,000 conversations/day at launch
- NFR-009: Scale to 100,000 conversations/day within 6 months

Reliability:
- NFR-010: 99.9% uptime SLA
- NFR-011: Graceful degradation if AI service unavailable

Usability:
- NFR-012: Agents can use with <10 minutes training
- NFR-013: WCAG 2.1 AA accessibility compliance
```

---

### 7. Technical Constraints

**Purpose:** Technology limitations and requirements

**What to Include:**

- Existing systems to integrate with
- Technology stack requirements
- Infrastructure constraints
- Budget limitations
- Timeline constraints

**Example:**

```
Integrations:
- Must integrate with existing Zendesk system
- Must use company SSO (Okta)
- Must log to existing Datadog monitoring

Technology Stack:
- Backend: Python (existing team expertise)
- LLM: OpenAI GPT-4 (approved vendor)
- Vector DB: Pinecone or Weaviate (to be decided)
- Frontend: React (existing stack)

Infrastructure:
- Deploy on existing AWS infrastructure
- Use existing CI/CD pipelines (GitHub Actions)

Budget:
- OpenAI API budget: $5,000/month maximum
- Infrastructure: $2,000/month maximum

Timeline:
- MVP must launch within 10 weeks
- Full feature set within 16 weeks
```

---

### 8. Data Requirements

**Purpose:** What data is needed and how it's managed

**Structure:**

- Data sources
- Data models
- Data privacy
- Data retention

**Example:**

```
Data Sources:
- Knowledge base articles (500+ articles in Notion)
- Historical support tickets (Zendesk, 2 years)
- Product documentation (GitHub docs)
- FAQ pages (company website)

Data Models:
- Conversations: id, customer_id, agent_id, messages[], status, satisfaction_rating
- Messages: id, sender, text, timestamp, ai_confidence
- Knowledge: id, title, content, embeddings, category, last_updated

Data Privacy:
- PII must be redacted before AI processing
- Conversation data retained for 90 days
- Analytics data aggregated and anonymized
- GDPR right-to-delete compliance

Data Security:
- Encrypt customer data at rest (AES-256)
- Encrypt in transit (TLS 1.3)
- Role-based access to conversation data
```

---

### 9. UI/UX Requirements

**Purpose:** How users interact with the system

**What to Include:**

- User flows
- Interface requirements
- Design constraints
- Accessibility needs

**Example:**

```
Customer Interface:
- Chat widget in bottom-right corner
- Typing indicators and response time estimates
- Clear "Talk to a human" button always visible
- Conversation history accessible for 30 days

Agent Interface:
- Side pane