spec-product-prd（R2：基于方案生成 PRD）

概览

R2 的目标是把 {FEATURE_DIR}/requirements/solution.md 的推荐决策转写为 {FEATURE_DIR}/requirements/prd.md：让研发能拆任务、QA 能写用例、干系人能评审与验收。

• 可验证优先：PRD 的核心是 场景 + 业务规则 + AC（可测试）
• 不确定性收敛：PRD 中不出现“待确认问题 / Open Questions”清单；未知统一进验证清单（Owner/截止/信号/动作）
• 不重复 R1：方案对比/为何选择/讨论过程留在 solution.md；PRD 只写交付规格

开始时宣布：「我正在使用 spec-product-prd 技能基于 solution.md 生成可验收 PRD（prd.md）。」

何时使用 / 不使用

• 使用时机
  • R1 已完成并产出 requirements/solution.md，需要把交付规格（范围/AC/里程碑/风险依赖）冻结为独立 PRD 评审
• 不要用在
  • spec-context 失败（上下文定位失败）→ 立刻停止
  • requirements/solution.md 不存在 / 明显未收敛（缺结论摘要/范围 In-Out/推荐方案/验证清单）→ 停止并回到 R1

输入 / 输出（落盘约定）

• 硬门禁输入：FEATURE_DIR（必须由 spec-context 获取）
• 读取
  • {FEATURE_DIR}/requirements/solution.md（必读，作为唯一决策入口）
  • {FEATURE_DIR}/requirements/raw.md（按需：补证据入口/原始措辞）
  • project/memory/glossary.md（如存在：术语与口径）
• 写入
  • {FEATURE_DIR}/requirements/prd.md（R2 产物，优先按模板生成）

门禁（必须先过，否则停止）

REQUIRED SUB-SKILL：先满足 spec-context 门禁并回显 FEATURE_DIR=...（允许 (reuse)）。

• spec-context 失败 → 停止
• {FEATURE_DIR}/requirements/solution.md 缺失 → 停止（不得“先出一版 PRD 再说”）

违反门禁=违反精神：无论“时间紧/老板催/流程卡点”，都禁止猜路径、禁止跳过 solution.md 硬写 PRD。

核心流程（规格化落盘；本技能不做下一步分流）

0) 防呆校验：若不应进入 R2，则停止并回到 using-aisdlc

如果上游路由结论为“跳过 R2（不单独产出 prd.md）”，则本技能不应继续执行（否则会破坏“唯一路由器”原则）。此时应停止并提示回到 using-aisdlc，由其决定在 solution.md 追加 Mini-PRD 或进入后续阶段。

本技能允许保留对“简单需求可跳过 R2”的口径理解，但仅作为防呆校验，不得在此直接给出下一步路由结论。

1) 从 solution.md 提取 PRD 的“可交付信息”

把 solution.md 中与交付/验收直接相关的内容抽成清单（不要发散新结论）：

• 目标一句话、In/Out、MVP 边界
• 核心场景（建议 ≤ 3 个）与成功标准
• 功能项（可拆解）与优先级（P0/P1/P2 或 Must/Should/Could/Won’t）
• 会影响 AC 的业务规则/口径（能引用就引用；不确定就进验证清单）
• 已知风险/依赖/假设（转写到 PRD 的验证清单表）

2) 用模板生成/更新 {FEATURE_DIR}/requirements/prd.md

优先对齐模板：<本SKILL.md目录>/assets/prd-template.md（只借结构，不把未知当已知）。

写作要求（最容易跑偏的点）：

• 场景驱动：第 3 节场景要能直接导出第 6 节 AC
• AC 可测试：每条 AC 都能写成“输入/操作/期望结果”而非主观描述
• 优先级对齐里程碑：MVP 至少覆盖 P0/Must；Out/Won’t 口径明确
• 不确定性只出现一次：只写在第 8 节“风险/依赖与验证清单”表里

3) R2 自检（写完立刻过一遍）

• In/Out 与 solution.md 一致，且不歧义
• 每个核心场景都有 AC（可直接转测试用例）
• 功能优先级与里程碑一致：MVP 覆盖 Must/P0
• 业务规则/口径可追溯；不可追溯的条目已进入验证清单
• 关键异常与边界覆盖会影响 AC 的情况（权限/失败/幂等等）
• 文档中不出现“待确认问题 / Open Questions / 待定项”清单

完成后：回到 using-aisdlc 路由下一步。

完成后输出（供 using-aisdlc 自动推进读取）

在回答末尾追加以下两段（不要省略）：

• 「本阶段产物已落盘。请回到 using-aisdlc 进行下一步路由（如未触发人工门禁，Router 可自动续跑）。」
• ROUTER_SUMMARY：

ROUTER_SUMMARY:
  stage: R2
  artifacts:
    - "{FEATURE_DIR}/requirements/prd.md"
  needs_human_review: true
  blocked: false
  block_reason: ""
  notes: "PRD 建议用户评审后再进入 R3/R4 或实现侧"

Quick reference（高频规则速查）

• 必须
  • 先跑 spec-context，只用 FEATURE_DIR 拼路径
  • 必读 solution.md，PRD 只做“转写/规格化”，不新增决策
  • PRD 里必须有：In/Out、核心场景、AC、验证清单（Owner/截止/信号/动作）
• 禁止
  • 猜路径（例如手写 .aisdlc/specs/...）
  • solution.md 缺失仍生成 PRD（“先写再问/先出一版”）
  • 写“待确认问题/Open Questions/待定项”列表（用验证清单表替代）

红旗清单（出现任一条：停止并纠正）

• 没跑 spec-context 就开始读写 requirements/*.md（或开始“猜 FEATURE_DIR”）
• solution.md 不存在/未收敛，却仍打算“先写 PRD 占坑”
• PRD 里出现 待确认 / Open Questions / 待定 / TBD 之类清单
• AC 充满主观词（“友好/清晰/合理/尽快”）而没有可验证动作
• 里程碑写了，但功能优先级与 MVP 范围对不上（MVP 不覆盖 P0/Must）

常见借口与反制（基线测试中的高频点）

一个好例子（把“待确认问题”改写成可执行验证清单）

坏写法（禁止）：

• 待确认：最大导出行数是多少？
• 待确认：性能指标是什么？

好写法（写到 PRD 第 8 节验证清单表）：