PRD 标准化生成

要解决什么问题

产品侧常见断层是：上游已经有一份「需求规格」（回答做什么），但评审和开发需要的是 PRD（回答怎么做）。若每份文档结构不一、缺少评审口径，评审会反复补洞，设计也容易脱离现有平台能力。

本技能把 需求规格作为唯一输入，输出可直接用于评审与开发的 标准化 PRD，并与上游 clarify 类产出形成明确上下游，而不是重复写一遍需求说明。

技能如何工作

流程大致分五步，并在开头用 Step 0 区分场景：

• [迭代模式]：用户给出平台名称或上下文已有平台信息时，从 ~/.miclaw/workspace/skills/platforms/{platform_name}/ 按分层路由加载知识库；INDEX.md 与 DESIGN-SPEC.md 必读，模块内文件按需求规格中的模块归属读取，用现有 features、rules、data、interfaces 约束功能、数据与接口，UI 对齐设计规范。
• [0-1 模式]：全新产品无平台知识库时跳过加载，走通用设计规范。

随后 解析需求规格（概述、范围、功能、数据、权限、非功能、依赖与风险）；缺关键信息会向你确认，不自行编造。按需求类型选模板（标准 / 精简 / 数据 / 集成），生成含 7 大章节 的 PRD，并在输出前 逐项过评审清单；不通过则回到生成步骤补全。默认保存为 docs/prd-{需求简称}.md 或你指定的路径。

适用边界与注意点

• 输入应是结构化需求规格；规格不完整时技能会追问，而不是硬写满文档。
• 迭代模式下功能与数据模型须基于平台现有能力，新增字段或接口需说明原因。
• 每次生成 PRD 不得跳过评审清单；功能描述应按页面/模块分组，而非平铺罗列。