{%- set prd = prd_management if prd_management else {} -%}
{%- set prd_file = prd.get('prd_file', 'docs/PRD.md') -%}
# XIII. Product Requirements Document (PRD) Management

## 13.1 Purpose of PRD

> **Although we use heuristic dialogue where requirements evolve through conversation, we need a PRD.md to record original requirements and their changes. Project requirements grow and change along with dialogue.**

PRD.md is used for:
- **Recording original requirements**: Preserve the user's initial requirement descriptions
- **Tracking requirement changes**: Record how requirements evolve through dialogue
- **Requirement traceability**: Understand the complete journey from proposal to implementation
- **Requirement statistics**: Overview of requirement status distribution

## 13.2 PRD Document Structure

PRD.md is located at `{{ prd_file }}` and contains:

### Requirement List

Each requirement includes:
- **Requirement ID**: REQ-001, REQ-002, ...
- **Title**: Concise requirement name
- **Original Description**: User's initial requirement description
- **Current Description**: Refined description after clarification and evolution
- **Status**: draft / confirmed / in_progress / completed / cancelled
- **Priority**: high / medium / low
- **Created At**: When the requirement was first recorded
- **Updated At**: When the requirement was last modified
- **Change History**: Record of requirement description changes

### Requirement Statistics

Auto-generated statistics of requirements by status.

## 13.3 PRD Usage Flow

### Requirement Proposal Phase

1. **User proposes requirement**: Describes requirement in dialogue
2. **AI records requirement**: 
   - Uses requirement clarification protocol to transform vague descriptions into structured requirements
   - Creates new requirement entry (REQ-XXX) in PRD.md
   - Records original and current descriptions

### Requirement Evolution Phase

1. **Requirement clarification**: Further define requirement details in dialogue
2. **Update PRD**: 
   - Update the requirement's current description
   - Record change reason in change history
   - Update requirement status (e.g., draft -> confirmed)

### Requirement Implementation Phase

1. **Start implementation**: Update requirement status to in_progress
2. **Complete implementation**: Update requirement status to completed
3. **Record association**: Associate the corresponding TASK-ID in the requirement

## 13.4 PRD Management Trigger Words

Use the following trigger phrases in dialogue, and the AI should proactively manage the PRD:

- "record requirement"
- "update PRD"
- "view requirements"
- "requirement status"
- "PRD"
- "requirements document"

## 13.5 Relationship Between PRD and Requirement Clarification Protocol

PRD is the **output artifact** of the requirement clarification protocol:

```
User proposes requirement
    |
    v
Requirement Clarification Protocol (structured requirement)
    |
    v
Record in PRD.md
    |
    v
Requirement evolution and implementation
```

## 13.6 PRD Update Timing

The AI should update PRD at these times:

1. **When new requirement is proposed**: Create new requirement entry
2. **After requirement clarification**: Update current description and change history
3. **When requirement status changes**: Update the status field
4. **When requirement implementation completes**: Update status to completed, associate TASK-ID

## 13.7 PRD Best Practices

### Requirement Description Standards
- **Original Description**: Keep user's exact words, no modification
- **Current Description**: Structured description after clarification
- **Change Reason**: Clearly explain why the requirement changed

### Requirement Status Flow
```
draft -> confirmed -> in_progress -> completed
  |                      |
  v                      v
cancelled            cancelled
```

### Requirement Association
- Requirements can be associated with TASK-IDs
- One requirement may correspond to multiple tasks
- Record associated task IDs in the requirement

---

