prd

name	prd
description	Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or creating a PRD.
disable-model-invocation	true
argument-hint	[feature description]

PRD Generator

Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation.

---

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 tasks/prd-[feature-name].md

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 experience
   B. Add new functionality
   C. Fix existing issues
   D. Other: [please specify]

2. 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" for quick iteration.

---

Step 2: PRD Structure

Generate the PRD with these sections:

1. Introduction/Overview

Brief description of the feature and the problem it solves.

2. Goals

Specific, measurable objectives (bullet list).

3. User Stories

Each story needs:

• Title: Short descriptive name
• Description: "As a [user], I want [feature] so that [benefit]"
• Acceptance Criteria: Verifiable checklist of what "done" means

Each story should be small enough to implement in one focused session.

Format:

### US-001: [Title]
**Description:** As a [user], I want [feature] so that [benefit].

**Acceptance Criteria:**
- [ ] Specific verifiable criterion
- [ ] Another criterion
- [ ] cargo fmt --check passes
- [ ] cargo clippy passes
- [ ] cargo test passes

Important:

• Acceptance criteria must be verifiable, not vague
• "Works correctly" is bad
• "Endpoint returns 200 with valid JSON" is good

4. Functional Requirements

Numbered list of specific functionalities:

• "FR-1: The system must allow users to..."
• "FR-2: When a user clicks X, the system must..."

5. Non-Goals (Out of Scope)

What this feature will NOT include.

6. Technical Considerations

• Known constraints or dependencies
• Integration points with existing Rivetr systems
• Performance requirements

7. Success Metrics

How will success be measured?

8. Open Questions

Remaining questions or areas needing clarification.

---

Rivetr-Specific Considerations

When creating PRDs for Rivetr, consider:

• Backend (Rust): API routes in src/api/, database in src/db/
• Frontend (React): Components in frontend/src/
• Container Runtime: May need to update ContainerRuntime trait
• Database: SQLite with SQLx, migrations in migrations/

---

Output

• Format: Markdown (.md)
• Location: tasks/
• Filename: prd-[feature-name].md (kebab-case)

---

Checklist

Before saving the PRD:

• Asked clarifying questions with lettered options
• Incorporated user's answers
• User stories are small and specific
• Functional requirements are numbered and unambiguous
• Non-goals section defines clear boundaries
• Saved to tasks/prd-[feature-name].md