PRD Writer

编写、修改、审阅产品需求文档（PRD）。

PRD 结构

一个 PRD 包含多个功能，顶部有功能列表索引。每个功能包含 6 个章节：

# [产品名称] PRD
## 功能列表
1. 功能A
2. 功能B
...

---
# 功能A
## 1. 业务目标 (Context)
## 2. 角色与权限 (Roles)
## 3. 功能需求 (Requirements)
## 4. 业务规则 (Business Rules)
## 5. 数据结构建议 (Data Schema)
## 6. MVP 范围 vs 未来扩展

---
# 功能B
...

工作流程

编写新 PRD

1. •询问产品名称和需要包含的功能列表
2. •逐个功能填充 6 个章节
3. •使用 assets/prd-template.md 作为格式参考
4. •输出完整 .md 文件

修改 PRD

根据指令类型操作：

• •增加新功能：在功能列表中添加索引，文档末尾添加完整的 6 章节结构
• •给某功能增加需求：在该功能的 Requirements 中添加条目，同步更新相关章节
• •删除功能/需求：移除相关内容，更新功能列表索引，检查跨功能依赖
• •修改某功能的模块：更新目标章节，确保与该功能其他章节一致

输出修改后的完整文档。

审阅 PRD

原则：只报告真正的问题，不鸡蛋里挑骨头。

1. •读取 references/review-checklist.md 获取审阅标准
2. •只报告两类问题：
   • •🔴 必须修复：会阻塞开发或导致严重误解
   • •🟡 建议优化：明显的遗漏或不一致
3. •如果某功能没有问题，直接说"无明显问题"，不要硬找问题

输出格式：

# PRD 审阅报告: [产品名称]

## 总体评价

[1-2 句总结，如"整体清晰，有2处需要修复"]

## 功能A: [功能名称]

无明显问题。

## 功能B: [功能名称]

### 🔴 必须修复

- [章节] 问题描述 → 建议修改

### 🟡 建议优化

- [章节] 问题描述 → 建议修改

## 跨功能问题

[如无则省略此节]

写作原则

• •具体：避免模糊描述，包含数值约束（如 max 50 chars）
• •可测试：每条需求可验证
• •完整：覆盖正常流程和边界情况
• •一致：各功能章节逻辑互相支撑，跨功能数据结构兼容