prd

name	prd
description	Create PRD (Product Requirements Document) for a project. Use when user needs to write PRD, create product requirements, plan features, or mentions PRD/product requirements/feature spec.
argument-hint	[module or feature name]
allowed-tools	Read Grep Glob Bash Write Edit

Create PRD (Product Requirements Document)

You are a professional Product Manager. Create detailed, actionable PRDs.

Input

• Module/feature to write PRD for: $ARGUMENTS
• If no argument provided, ask the user which module/feature needs a PRD.

Process

Step 1: Gather Context

1. Read ideas: Find and read docs/00_idea/idea.md or files in docs/00_idea/
2. Read overview (if exists): docs/01_overview/
3. Read codebase: Check package.json, pyproject.toml, directory structure to understand current tech stack
4. Read existing PRDs (if any): docs/02_prd/ to avoid duplication

Step 2: Define Scope

• Identify the exact module/feature from the argument or ask the user
• Clearly separate MVP vs nice-to-have
• List what's IN scope and OUT of scope

Step 3: Write PRD

Write the PRD using the template below. The PRD must be:

• Specific, measurable, and unambiguous
• Have clear acceptance criteria for each requirement
• Prioritize MVP first
• Written in English

Step 4: Assign PRD ID

• Each PRD gets a unique ID: prd-001, prd-002, etc.
• Check docs/02_prd/__00_index.md for the next available ID
• Include the PRD ID in the document header

Step 5: Save File

• Save to docs/02_prd/prd-<xxx>-<module-name>.md (e.g. prd-001-ghost-runner-api.md)
• If docs/02_prd/ doesn't exist → create it
• If file already exists → ask user to overwrite or create a new version

Step 6: Update Index

• If docs/02_prd/__00_index.md doesn't exist → create it from references/prd-index-template.md
• Add a new row to the index table with: PRD ID, module name, file path, status (Draft), created date
• This index allows referencing by PRD ID during implementation (e.g. "implement prd-001")

Template

Use the template in references/prd-document-template.md to generate the PRD.

Important Notes

• PRD describes WHAT and WHY, never HOW — no code, no implementation details, no technical architecture
• Every Functional Requirement must have clear Acceptance Criteria
• UI requirements describe layout and interactions at a conceptual level, not component code
• Always include Milestones section with clear phases
• Reference idea.md when explaining context
• Technical details (API spec, data models, code structure) belong in docs/03_impl/, not in PRD