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