generate-prd

name	generate-prd
description	Executes the full PM workflow: office-hours interrogation → scope-mode selection → PRD generation. Must not skip office-hours step.

Generate PRD — 完整执行流程

前置条件检查

1. office-hours 已完成？ → 否则先执行 Section 1
2. scope-mode 已选择？  → 否则先执行 Section 2
3. 以上完成后执行 Section 3（写 PRD）

---

Section 1：Office Hours 执行清单

对用户的每个问题，做到以下两点：

• 记录用户的原始回答（不要改写）
• PM 追问：如果回答太模糊，继续追问直到具体

### Q1：你在解决谁的什么问题？

模糊答案识别：
  ❌ "我想帮用户管理任务"
  ❌ "所有需要提高效率的人"
  ✅ "在职场的项目经理，在多项目并行时跨工具同步任务状态太痛"

追问模板：
  "说得更具体一点——是什么类型的用户，在什么场景下，
   遇到了什么让他们觉得'现在的工具不够用'的时刻？"

### Q2：他们现在怎么解决这个问题？

模糊答案识别：
  ❌ "没有好的解决方案"
  ❌ "他们用现有的工具但不满意"
  ✅ "用 Notion + 飞书 + 手动复制粘贴，每周花 3-4 小时同步，
      经常出现版本不一致导致会议上争论数据"

追问模板：
  "他们现在具体用什么工具？每天或每周在这上面花多少时间？
   最让他们沮丧的具体场景是什么？"

### Q3：你描述的解法是唯一解法吗？

引导模板：
  "你说要做 {X}。但解决'{底层问题}'的方式可能还有：
   - 更好的集成现有工具（API 连接）
   - 自动化同步脚本
   - 重新设计工作流程本身
   为什么你选择了 {X} 而不是这些？"

### Q4：最小可验证版本是什么？

引导模板：
  "如果你明天必须上线一个可以获得真实用户反馈的版本，
   你会删掉什么？保留什么？预计需要几天实现？"

### Q5：什么情况下你会停止做这个？

引导模板：
  "3 个月后，哪些指标的结果会让你决定放弃这个方向？
   例如：'如果使用率低于 X%'或'如果用户留存在第一周后骤降'"

### Q6：你在对这个需求撒谎吗？

引导模板：
  "最后一个问题，也是最难的。
   你对这个需求最大的一个内心疑虑是什么？
   有没有什么数据你没提到、假设你没验证、风险你在回避？"

Office Hours 总结输出

完成 6 个问题后，输出以下总结：

## PM 重构

**原始需求**：[用户最开始说的]

**真实问题**：[PM 提炼的底层痛点]

**关键洞察**：
- [洞察 1：可能颠覆原始需求方向的发现]
- [洞察 2]

**三种实现路径**：
| 路径 | 描述 | 预估工作量 | 风险 |
|------|------|----------|------|
| A（最小） | ... | X天 | 低 |
| B（中等） | ... | X天 | 中 |
| C（完整） | ... | X天 | 高 |

**PM 推荐**：路径 {A/B/C}，原因：...

---

Section 2：Scope Mode 选择

向用户展示：

基于 office-hours 分析，请选择本次的范围策略：

1. 📈 EXPANSION
   做比 office-hours 推荐更完整的版本，探索完整愿景
   → 适合：新产品初期，资源充裕，需要想象力

2. 🎯 SELECTIVE EXPANSION（推荐）
   以 office-hours 推荐路径为基线 + 可选扩展项
   → 适合：多数场景的默认选择

3. 🔒 HOLD SCOPE
   严格执行 office-hours 推荐的最小路径，拒绝任何扩展
   → 适合：时间紧、之前已 scope 失控过

4. ✂️ REDUCTION
   已有 PRD 太大，需要裁剪找出真正的 MVP
   → 适合：PRD 超出实际能力，需要砍功能

选择后继续生成 PRD。

---

Section 3：PRD 写作要点

死亡条件（来自 Q5，必须写）

## 死亡条件

以下任一情况发生，立即暂停并重新评估：

| 条件 | 可观测指标 | 时间窗口 | 决策 |
|------|----------|---------|------|
| 用户不用 | DAU < X，或 7 日留存 < Y% | 上线后 4 周 | 转向 or 放弃 |
| 技术不可行 | ... | 开发启动后 2 周 | 调整方案 |
| 市场假设错误 | ... | 3 个月 | 重新 office-hours |

验收标准写法规则

❌ 错误："系统响应要快"
✅ 正确："API 响应时间 < 200ms (P95，正常负载)"

❌ 错误："用户体验好"
✅ 正确："完成核心操作的用户，满意度评分 ≥ 4.2/5（上线 30 天后调研）"

❌ 错误："支持常见格式"
✅ 正确："支持 .csv, .xlsx, .json 三种格式，单文件 ≤ 10MB"

MoSCoW 评分示例（SELECTIVE EXPANSION 模式）

| ID | 功能 | 优先级 | RICE 分 | 工期估计 | 说明 |
|----|------|--------|---------|---------|------|
| F001 | 核心功能 | Must | — | 5天 | 基线，不可删 |
| F002 | 重要辅助 | Should | R:8 I:7 C:80% E:3 = 18.7 | 3天 | 推荐做 |
| F003 | 可选增强 | Could | R:5 I:4 C:60% E:2 = 6 | 2天 | 用户可选加 |
| F004 | 非本期 | Won't | — | — | 原因：{具体} |

---

质量门控

node scripts/workflow.js validate-doc prd

自动检查项（validator 规则）：

• Section 0 存在（含 office-hours 关键洞察）
• 至少一个 KR 含数字和时间范围（regex: /\d+.*\d+(天|周|月|年|%|人)/ ）
• 所有 Must 功能有 Gherkin Scenario: 块
• 存在 Out of Scope 或 范围外 小节
• 存在 死亡条件 小节
• 不含模糊词：易于使用、用户友好、快速响应、simple、easy、seamless
• 字数 600-2000

---

接力

docs/prd.md 输出并通过 validate-doc prd 验证后： → 下一步：traceability-matrix（生成追溯矩阵）→ 通知 Orchestrator 推进到 PRD_REVIEW