#Create PRD

Create a PRD by interviewing the user about their spec. Output format: prds/YYYY-MM-DD_type_name/PRD.md.

#Workflow

#Step 1: Gather PRD Metadata

Before starting the interview, ask for:

1. Type (conventional commit type): feat, fix, refactor, chore, docs, style, test, perf, ci, build
2. Short name: A kebab-case name describing the PRD (e.g., inventory-ddd-migration, user-auth, api-caching)

The output will be a folder: prds/YYYY-MM-DD_type_name/ With main file: prds/YYYY-MM-DD_type_name/PRD.md

Example: prds/2026-01-22_refactor_inventory-ddd-migration/PRD.md

#Step 2: Create PRD Folder

Create the PRD folder structure:

mkdir -p prds/YYYY-MM-DD_type_name/tasks

#Step 3: Read Current Documentation

Read /docs and CLAUDE.md to understand the project's conventions and best practices.

#Step 4: Conduct Interview

Based on the spec content provided, conduct an in-depth interview with the user using the AskUserQuestion tool. Ask about:

• Technical implementation details and decisions
• UI & UX considerations and preferences
• Concerns and potential risks
• Tradeoffs between different approaches
• Edge cases and error handling
• Performance and scalability considerations
• Security implications
• Integration points and dependencies
• User flows and journeys
• Data models and state management
• Testing strategies
• Deployment and rollout considerations

Important interview rules:

• Ask NON-OBVIOUS questions — avoid questions already answered in the spec
• Be thorough and continue interviewing until you have a complete picture
• Ask follow-up questions based on user responses
• Explore areas where the spec is vague or incomplete
• Challenge assumptions and explore alternatives
• Ask as many questions as needed — this is a critical phase, do not limit yourself

Continue the interview process iteratively until:

• All major areas have been covered
• The user indicates they're satisfied with the depth
• You have enough information to write a comprehensive PRD

#Step 5: Write PRD

Once the interview is complete, write the PRD to prds/YYYY-MM-DD_type_name/PRD.md with:

# PRD: [Project Name]

**Created**: YYYY-MM-DD
**Type**: feat|fix|refactor|...
**Status**: Draft

---

## Executive Summary

[1-2 paragraphs summarizing the project]

---

## Problem Statement

[What problem are we solving? Why now?]

---

## Goals and Success Metrics

| Goal | Metric | Target |
|------|--------|--------|
| [Goal 1] | [How measured] | [Target value] |

---

## User Stories

### US-1: [Title]
As a [user], I want [action] so that [benefit].

**Acceptance Criteria:**
- [ ] [Criterion 1]
- [ ] [Criterion 2]

---

## Technical Architecture

### Overview
[High-level architecture decisions]

### Data Models
[Entity definitions, relationships]

### API Specifications
[Endpoints, request/response formats]

---

## UI/UX Specifications

[Wireframes, user flows, design decisions]

---

## Security Considerations

[Authentication, authorization, data protection]

---

## Testing Strategy

[Unit, integration, E2E test approach]

---

## Risks and Mitigations

| Risk | Impact | Likelihood | Mitigation |
|------|--------|------------|------------|
| [Risk] | High/Med/Low | High/Med/Low | [How to mitigate] |

---

## Open Questions

- [ ] [Question 1]
- [ ] [Question 2]

---

## Tasks

> Tasks will be generated by `/plan-tasks`. Run `/plan-tasks` after this PRD is complete.

| Task | Description | Status |
|------|-------------|--------|
| _Run /plan-tasks to generate tasks_ | | |

#Step 6: Hand Off to Planning

After the PRD is written, suggest the user run /plan-tasks to generate detailed task files from the PRD.

#Rules

1. Interview before writing — Never write the PRD without an in-depth interview
2. Question quality — Avoid obvious questions; challenge assumptions
3. Cover all areas — Technical, UX, security, performance, testing
4. Tasks deferred — The PRD seeds the Tasks table but /plan-tasks fills it
5. Date is today — Always use the current date in the folder name