用途
prd-doc-writer 用于撰写和迭代打磨 PRD/需求文档。它把使用者定位为“伙伴”（Partner/搭子），强调通过持续的提问、沟通和阶段性确认，与用户共同构建 PRD，而不是单向输出。每一步关键进展都必须获得用户的明确认可。
核心理念
- 故事是唯一载体：整个 PRD 的主体是一系列按逻辑顺序排列的用户故事。
- 故事必须自包含：每个故事卡片都必须包含实现该功能所需的需求信息，包括业务逻辑、用户可见行为（页面/状态/提示文案）、边界约束和验收标准。执行方阅读一张卡片即可理解“用户要什么、系统应如何表现、如何验收”。
- 叙事逻辑高于一切：功能点不能孤立存在，必须先引导用户建立宏观的“用户旅程地图”或“业务主流程”，再将所有用户故事串联在这条主线上，形成连贯、分阶段的开发蓝图。
- 视觉对齐是必须：对于任何涉及用户界面（UI）的用户故事，必须使用 ASCII 线框图进行布局草稿的绘制与确认。ASCII 线框图用于表达“静态布局”（页面元素的位置、组合、层次关系）；Mermaid 图用于表达“动态行为”（流程、状态流转、时序交互）。两者互补，共同减少需求歧义。
- 用图减少歧义：使用 Mermaid 图把关键的“流程/状态/交互”讲清楚，保持需求视角，避免写成技术实现细节。流程图（必填）表达核心用户操作流与关键分支/异常；状态图（条件必填）在存在明确“状态流转对象”（订单/任务/工单/审核等）时补充生命周期状态机图；时序图（可选）仅在“时序/并发/重试/超时”会影响用户可见结果时补充。
交互模型
采用确认驱动的“伙伴”模式：
- “一问一答一确认”节奏：得到一个答案后，先用自己的话复述并寻求确认，确保没有误解，再进行下一步。
- 严禁“自作主张”：不根据想象猜测或补充任何用户未明确提供的信息，所有内容都必须源于与用户的对话和共识。
- 区分“讨论”与“生成”：在用户下达最终生成指令前，所有回复都应是简短的、对话式的、以澄清和确认为目的，避免输出大段未经确认的文档片段。
- 显式暴露假设与风险：发现需求存在缺失、冲突、实现风险或需要额外输入时，必须主动指出、记录并征求用户确认，而不是默认留白或默许模糊描述。
使用方式：三步确认法
第一步：定义框架与寻求共识
与用户初步沟通后，引导用户梳理出产品的核心业务流程或用户旅程，并划分为几个逻辑阶段。梳理出初步阶段划分后，必须向用户进行一次明确确认，例如：“我们梳理出的这几个阶段分别是：1.[...] 2.[...] 3.[...]。这个作为我们后续讨论的‘地图’，您看可以吗？或者有需要调整的地方吗？”在得到用户肯定答复前，严禁进入下一步。确认后，补一张 Mermaid 流程图，画出“核心用户操作流（含关键分支/异常）”，再做一次快速确认。
第二步：逐个故事击破与单点确认
按照定义好的阶段顺序，引导用户逐一详细讨论每个用户故事。系统性地提问，以填满输出格式中定义的所有信息模块。收集信息时，引导用户补齐关键字段的业务定义、状态枚举、评分或计算公式、用户可见文案/提示，以及与其它故事的依赖关系；若资料缺失，必须提出追问或明确记录待确认事项。在进入验收标准讨论前，先确认所有异常/失败/降级路径与 Happy Path 一并梳理清楚。
完成一个用户故事的所有细节讨论后，必须进行一次“单点确认”，例如：“好的，关于‘US-01: ...’这个故事，我们已定义了所有细节。我简单总结一下：[...]。您看这个故事的描述是否完整和准确？如果没问题，我们就正式把它‘定稿’，然后开始讨论下一个故事。”
UI 故事专项：当讨论的用户故事涉及用户界面（UI）时，在讨论完“业务规则与逻辑”后、进入“验收标准”讨论前，必须启动“ASCII 线框图”绘制流程，用字符绘制布局草稿，请用户审阅并提出调整意见。用户确认无误后，才可邀请用户开始讨论下一个故事。
第三步：总结确认与最终生成
当所有阶段和用户故事都已讨论完毕时，不能直接生成文档，必须先向用户发起“终稿确认请求”，例如：“我们似乎已经讨论完了所有预定的阶段和用户故事。根据我们所有的讨论和确认，我准备为您生成最终的 PRD 文档。在生成之前，我们是否需要快速回顾一下要点，或者您觉得还有遗漏吗？如果没问题，请您告诉我‘可以生成了’。”只有在得到用户明确的“可以生成”或类似最终指令后，才能调用所有达成共识的记忆，严格按照输出格式模板，一次性、完整地生成最终的 PRD 文档。
输出格式与示例
最终 PRD 输出模板见 assets/prd-template.md（严格按该模板生成）。示例 US 参考见 references/example-us01.md；Mermaid 图示例见 references/mermaid-examples.md；UI 线框图质量参考见 references/ui-wireframe-examples.md。
PRD 版本管理（总集/台账）
PRD 写完后需要进行版本管理：在项目仓库里维护一份 PRD 总集（台账），做到“每个 PRD 一行，永远指向最新 PRD 链接（不在总集里保留历史）”。历史追溯交给 Git。
- 推荐默认路径（如果用户已有规范，以用户为准）：PRD 总集为 docs/PRD_REGISTRY.md；单个 PRD 为 docs/prd/<版本>.md（例如 docs/prd/PRD-001.md）。references/prd-registry-demo.md 仅作为示例；真实总集应放在项目仓库。
- 执行时机：在最终 PRD 已输出之后（收尾管理动作），可选输出一行“可直接粘贴到项目仓库 PRD 总集”的表格行。
- 需要用户提供的最小信息：版本（该 PRD 在总集里的固定标识，例如 PRD-001）、PRD 链接（项目仓库中的最新 PRD 文件路径，例如 docs/prd/PRD-001.md）、（可选）PRD 总集路径（默认 docs/PRD_REGISTRY.md）。如需更新总集，向用户确认即可，不影响 PRD 本体输出。
- 总集表格行输出格式：输出单行 Markdown 表格行：| <版本> | <标题> | <需求内容（详细摘要）> | <PRD链接> |。约束：<需求内容（详细摘要）> 使用自然语言写清“目标/范围/关键规则/边界/异常/非目标”，尽量 3–8 句；为避免破坏 Markdown 表格，四个字段内都不要包含 | 字符。
适用场景
适用于需要与用户协作梳理产品需求、撰写结构化 PRD 的场景，尤其是需求涉及多阶段用户旅程、多个用户故事、UI 布局对齐、流程与状态流转表达，以及需要维护 PRD 版本台账的项目。
限制
该技能强调严格的分阶段确认，未获得用户明确确认前不得进入下一步或生成文档；不得猜测或补充用户未明确提供的信息；涉及 UI 的故事必须经过 ASCII 线框图确认；最终生成必须严格按 assets/prd-template.md 模板执行。关于具体收费、价格、平台支持范围等信息，资料中暂未提供。