用途
本技能用于撰写产品需求文档（PRD），是 SDLC 文档流程的第二阶段：发现（discovery）→ 需求定义（requirements-definition）→ 方案设计（solution-design）。它消费 discovery 技能产出的探索简报，生成供方案设计阶段使用的 PRD。与 discovery 一样，该技能不做代码修改、不产生提交；仅在确保“当前行为”章节准确时阅读代码。
输入约定：探索简报
主要输入是探索简报（discovery 的输出）。开始写作前先解析输入：
- 简报已存在（附带、引用或出现在对话中）。完整阅读后校验：
- 检查处置结论（disposition），必须为 proceed。
- proceed：按下述交接映射消费简报。
- spike：告知用户简报要求先做实验；若用户坚持，可写 PRD，但须将未验证假设列入“待决问题”作为显式风险。
- park 或 dissolve：停止并询问。PRD 与该简报自身结论相反，须由用户明确推翻，并在 PRD 头部记录该推翻。
- 检查方向：proceed 必须指明选定方向与备选方向；缺失时只问一个问题确定，不得猜测。
- 无简报。说明经一轮 discovery 后 PRD 会更强，并推荐 discovery 技能。若用户拒绝，或对话已含等价材料（痛点、选项、已定方向），先将材料整理成简报式笔记，再据此写 PRD。两种情况都需为 PRD 记录来源。
不得编造简报、代码或用户未提供的问题与当前行为内容；无来源的需求只是带编号的猜测。
交接映射（简报 → PRD）
机械套用后精修：
- §1 问题地图 → §1 问题：选有真实成本的根因痛点，把症状归入根因，删除标记为“偏好”的痛点或移至非目标。
- §1 问题地图 + 变通办法 → §2 当前行为：用中性语言描述现状，纳入简报认为不足的变通办法及原因。
- §5 选定方向 + §4 有意非目标 → §3 目标：每条目标须回应一句问题描述；简报非目标转为“本版本不做”条目并保留原因；在此指明一次备选方向。
- §2 领先选项影响 → §4 用户故事：为选定方向带来的能力各写一条故事，每个故事一个目标；不为备选方向写故事。
- §3 标记为“昂贵”或“spike”的假设 → §8 待决问题：连同选项保留；标记为“廉价”的假设当场确认，不保留。
- §2 被拒选项 → 附录 A：连同原因复制；设计规格的 ADR 引用此附录，不重开辩论。
- §3 来源列 → 功能需求标注：当需求依赖来源为“直觉”的假设时，标记该需求，供评审与设计阶段识别未验证基础。
工作流程
- 按上述约定解析输入。如需用户访谈，只问问题与当前行为，不问方案细节。
- 阅读 references/ste-writing-rules.md，全文遵守其写作规则。
- 复制 assets/prd-template.md 作为起始文件，保留章节顺序，不删除章节；某章节不适用时写一句话说明原因。
- 按顺序填写：问题 → 当前行为 → 目标 → 用户故事 → 功能需求 → 非功能需求 → 验收标准 → 待决问题 → 附录 A。每章节约束下一章节。
- 执行自检（见下）。
- 将输出写入 Markdown 文件并呈现，不要把完整 PRD 粘贴到对话中。
章节规则
- 问题：说明痛点、代价及代价增长原因，不点名方案。检验方式：删除其余内容后，问题章节仍须成立。
- 当前行为：中性描述现状，包含变通办法及不足原因，提前回答“为什么不能直接……”之类评审疑问。
- 目标：一条能力陈述 + 可衡量成功标准 + 显式非目标。每条目标须回应一句问题描述；无对应问题的目标属范围蔓延；无对应目标的问题须补条款或移至非目标。
- 用户故事：简短、以角色驱动，每个一个目标。STE 中写能力陈述（“操作员可以……”），不用第一人称愿望；故事承载原因，不承载精度。
- 功能需求：表格含 ID、需求及“追溯到”列（故事 ID）；使用 must，不用 shall 或 should；每条功能需求至少追溯一条故事；一行一条，拆分复合需求；标记依赖直觉来源假设的需求。
- 非功能需求：表格含 ID、类别、需求；不追溯到单条故事，而横跨故事；每条须可衡量或可检查（如“系统在小于 5 秒内编译 20 万 token 输入”），不得写成用户故事。
- 验收标准：按故事分组，写为测试步骤（命令句 + “确认……”检查），人和机器均可无歧义执行；验收标准把关故事完成，成功指标衡量产品长期表现，二者不混用。
- 待决问题：编号列出本 PRD 不做的决策并注明选项，来源为简报中昂贵未知项及写作中新发现，将在设计规格中转为 ADR。
- 附录 A — 被拒选项（仅当简报提供时）：连同原因复制；下游文档引用“附录 A，选项 (x)”。
自检清单
- 每条功能需求至少追溯一条故事；每条故事至少有一条功能需求。
- 每条目标映射一句问题描述，反之亦然。
- 非功能需求不写成用户故事，每条有数字、限制或二元检查。
- 每条验收标准以命令动词开头，且至少含一个“确认……”检查。
- 问题章节不点名任何方案组件。
- 若消费了简报：处置为 proceed，或头部记录了明确的推翻；所有“昂贵”假设在待决问题中；被拒选项在附录 A；直觉来源的功能需求已标记。
- 全文遵守 STE 规则（句长、批准用词替换、需求用 must）。
- 若用户要求标准英语而非 STE：保留结构与全部追溯规则，仅去掉 STE 风格约束。
下游约定
方案设计技能将：把每条功能与非功能需求 ID 放入范围清单，将每条待决问题解决为 ADR，并引用附录 A 而非重开已死分支的辩论。PRD 须让这三项操作可机械执行。
适用场景与限制
适用于已有探索简报、需要产出结构化可追溯需求文档的软件项目，尤其重视写作规范与需求来源追踪的团队。限制：不修改代码；依赖有效简报或等价材料；不替代方案设计与 ADR；STE 为默认风格，可经用户要求改为标准英语但保留结构与追溯规则。