Skill: xu4wang/pm-prd (version 0.1.0)

--- name: prd description: 产品经理专用的 PRD(产品需求文档)生成、优化与扩展工具。用于从自然语言描述创建结构化 PRD、对现有 PRD 进行澄清式审阅以补全模糊点、或向已有 PRD 追加新功能。当用户提到"写 PRD""生成产品需求文档""需求文档""优化/澄清 PRD""review PRD""给 PRD 加功能""PRD 新增需求"时使用此技能。 --- # PRD Skill - 产品需求文档生成、优化与扩展 本技能为产品经理提供三个核心工作流: 1. **生成模式 (generate)**: 从自然语言功能描述创建一份结构化 PRD 2. **澄清模式 (clarify)**: 审阅已有 PRD,识别模糊点并通过针对性问题帮助用户补全 3. **扩展模式 (extend)**: 向已有 PRD 追加新功能,保持术语/编号/优先级一致 ## 模式判定 根据 `$ARGUMENTS` 和对话上下文判断走哪个模式: - **扩展模式**: 参数同时包含一个**已存在的 PRD 文件路径**和一段**新功能的自然语言描述**(或用户明确说"给这个 PRD 加 xxx 功能""PRD 新增 xxx") - **澄清模式**: 参数**只**含有指向已存在文件的路径,无新功能描述;或用户明确说"优化/澄清/review 这个 PRD" - **生成模式**: 其他情况(纯自然语言功能描述,无文件路径) - 文件存在但内容为空/全是占位符 → 当作生成模式处理 - 扩展和澄清的边界模糊时,看用户意图: "新增/追加/再加一个/还要支持" → 扩展;"这里没写清楚/含糊/review" → 澄清 不确定时,直接问用户一句确认,不要默默猜错模式。 --- ## 模式一: 生成 PRD (Generate) ### 输入 用户通过 `$ARGUMENTS` 提供的功能/产品描述。关注 **What** 和 **Why**,不要陷入 **How**(技术栈、API、代码结构)。 ### 输出位置 默认写入当前工作目录下的 `./prds/<short-name>.md`: - 如果当前目录已经叫 `prd`、`prds`、`docs/prd` 或类似,直接写到 `./<short-name>.md` - `short-name` 从描述中提炼 2-4 个词,用连字符连接,例如 `user-auth`、`photo-albums`、`fix-payment-timeout` - 如果目标文件已存在,追加时间戳后缀避免覆盖(`<short-name>-YYYYMMDD.md`) - 写文件前用 Bash `mkdir -p` 确保目录存在 **不要**涉及任何 git 操作(不创建分支、不 commit、不读 git 状态)。 ### 执行流程 1. **解析输入**: 从功能描述中提取参与者 (actors)、操作 (actions)、数据 (data)、约束 (constraints) 2. **合理推测**: 对没明说的细节,基于行业标准和常见模式填默认值,并在"假设"章节记录 3. **限制澄清标记**: 最多保留 **3 个** `[NEEDS CLARIFICATION: 具体问题]` 标记,按优先级:范围 > 安全/隐私 > 用户体验 > 技术细节。有合理默认值的一律不标 4. **用户故事**: 按重要性排序 (P1/P2/P3),每个故事必须可独立测试、独立交付价值 (MVP 切片) 5. **功能需求**: 每条 `FR-NNN` 必须可测试、无歧义 6. **成功标准**: 每条 `SC-NNN` 必须可衡量、技术无关、以用户/业务视角描述 7. **使用下方模板**写入 PRD 文件 8. **质量自检**: 写完后对照"质量清单"逐项打勾,不过关就修改重写,最多迭代 3 次 ### PRD 模板 ```markdown # 产品需求文档: [功能名称] **创建时间**: [YYYY-MM-DD] **状态**: 草稿 **输入描述**: "$ARGUMENTS" ## 用户场景与测试 *(必填)* ### 用户故事 1 - [简要标题] (优先级: P1) [用通俗语言描述用户旅程] **优先级原因**: [为什么是 P1 - 业务价值、用户痛点] **独立测试**: [如何独立验证这个故事的价值,例如"通过 X 操作可完整体验并交付 Y 价值"] **验收场景**: 1. **给定** [初始状态],**当** [用户操作],**那么** [预期结果] 2. **给定** [初始状态],**当** [用户操作],**那么** [预期结果] --- ### 用户故事 2 - [简要标题] (优先级: P2) (结构同上) --- ### 用户故事 3 - [简要标题] (优先级: P3) (结构同上) --- ### 边界情况 - 当 [边界条件] 时会发生什么? - 系统如何处理 [错误场景]? - [并发 / 超时 / 空数据 / 权限越界 等] ## 需求 *(必填)* ### 功能需求 - **FR-001**: 系统必须 [具体能力] - **FR-002**: 用户必须能够 [关键交互] - **FR-003**: 系统必须 [数据需求] - **FR-004**: 系统必须 [行为] ### 关键实体 *(如涉及数据则包含)* - **[实体 1]**: [代表什么,关键属性,不含实现细节] - **[实体 2]**: [与其他实体的关系] ## 成功标准 *(必填)* ### 可衡量的结果 - **SC-001**: [用户可以在 N 分钟内完成 X] - **SC-002**: [N% 的用户在首次尝试时成功] - **SC-003**: [业务指标提升 N%] ## 假设 - [关于目标用户的假设] - [关于范围边界的假设] - [对现有系统的依赖] ## 超出范围 *(可选)* - [本次明确不做的事] ``` ### 质量清单 (Quality Checklist) 写完 PRD 后在内存中对照检查,不要写到文件里: **内容质量** - [ ] 不含实现细节(语言、框架、API) - [ ] 聚焦用户价值和业务需求 - [ ] 为非技术干系人可读 - [ ] 所有必填章节已填写 **需求完整性** - [ ] `[NEEDS CLARIFICATION]` 标记 ≤ 3 个 - [ ] 每条需求可测试、无歧义 - [ ] 成功标准可衡量、技术无关 - [ ] 所有验收场景已定义 - [ ] 边界情况已识别 - [ ] 范围边界清晰 - [ ] 依赖和假设已记录 **功能就绪度** - [ ] 每条功能需求都有清晰的验收标准 - [ ] 用户场景覆盖主流程 - [ ] 符合成功标准中定义的可衡量结果 ### 报告 写完后向用户报告: - PRD 文件路径 - 生成的用户故事数量和优先级分布 - 遗留的 `[NEEDS CLARIFICATION]` 清单(如有) - 建议下一步:"可运行 `/prd <path>` 进入澄清模式补全细节" --- ## 模式二: 澄清 PRD (Clarify) ### 目标 检测现有 PRD 中的模糊点或缺失的决策,**一次问一个问题**地与用户确认,把答案直接写回 PRD。总问题数上限 **5 个**。 ### 执行流程 1. **加载 PRD**: 读取用户指定的文件。如果文件不存在或为空,提示用户先运行生成模式 2. **结构化扫描**: 按以下分类检查每个类别的状态(清晰 / 部分 / 缺失),**不要**把原始扫描结果输出给用户: - **功能范围与行为**: 核心目标、成功标准、超出范围声明、用户角色区分 - **领域与数据模型**: 实体/属性/关系、唯一性、生命周期、数据量级 - **交互与 UX 流程**: 关键旅程、错误/空/加载态、可访问性/本地化 - **非功能属性**: 性能、可扩展性、可靠性、可观测性、安全隐私、合规 - **集成与外部依赖**: 外部服务、数据导入导出、协议版本 - **边缘情况**: 负面场景、限流、冲突解决 - **约束与权衡**: 技术约束、已拒绝的替代方案 - **术语一致性**: 术语表、避免的同义词 - **完成信号**: 验收标准可测试性 - **模糊占位符**: TODO、"robust"/"intuitive" 等无量化的形容词 3. **生成优先级问题队列** (≤5): - 每个问题必须可用多选(2-5 个互斥选项)或 ≤5 字的短答回答 - 只问答案能实质影响架构/数据模型/测试/UX/运营/合规的问题 - 类别平衡:先覆盖影响最大的未解决类别 - 排除已答问题、风格偏好、规划层的执行细节 - 如果候选 > 5,按(影响 × 不确定性)启发式选前 5 4. **顺序交互提问**: 一次**只问一个**问题,绝不提前泄露后续问题 **多选题格式**: ```markdown **Q[N]: [主题]** **推荐**: 选项 [X] — [1-2 句推理:最佳实践 / 类似实现常见模式 / 风险降低 / 与 PRD 既有目标一致] | 选项 | 描述 | |------|------| | A | [描述] | | B | [描述] | | C | [描述] | | 自定义 | 提供不同的 ≤5 字短答 | 你可以回复选项字母(如 "A")、说"是"或"推荐"接受推荐,或给出自己的 ≤5 字短答。 ``` **短答题格式**: ```markdown **Q[N]: [主题]** **建议**: [你建议的答案] — [简要理由] 格式: ≤5 字短答。回复"是"/"建议"接受,或给出你自己的答案。 ``` 5. **用户回答后**: - 如果用户说 "yes"/"是"/"推荐"/"建议",使用之前声明的推荐作为答案 - 否则验证答案映射到某选项或 ≤5 字约束,模糊则要求消歧(不计新问题) - 记录答案到工作内存,**立刻**把澄清应用到 PRD 对应章节并保存文件: - 功能模糊 → 更新或追加功能需求项 - 用户交互/角色 → 更新用户故事或角色子章节 - 数据形状/实体 → 更新关键实体 - 非功能约束 → 更新成功标准中的可衡量结果(把模糊形容词换成指标) - 边缘情况 → 在边界情况下追加 - 术语冲突 → 全文统一术语 - 若澄清使早先声明失效,**替换**掉旧声明而不是留矛盾文本 - 同时在 PRD 顶部维护 `## Clarifications` → `### Session YYYY-MM-DD` 子标题,追加一行 `- Q: <问题> → A: <最终答案>`。**同日多轮**: 如果当天已存在同名 session 标题,新会话使用 `### Session YYYY-MM-DD (2)`、`(3)` 递增编号,不要合并到已有 session 块 6. **停止条件**(满足任一即停): - 所有关键模糊已早期解决 - 用户发出完成信号("done"/"stop"/"好了") - 已问满 5 个问题 7. **最终报告**: - 已问/已答问题数量 - 更新的 PRD 文件路径 - 涉及的章节清单 - 覆盖范围摘要表(每个分类: 已解决 / 已推迟 / 清晰 / 未完成) - 建议下一步 ### 行为规则 - 如果没有发现有意义的模糊,直接回应:"未检测到值得正式澄清的关键模糊点",建议继续下一阶段 - 如果 PRD 文件缺失或为空,指示用户先走生成模式,**不要**在澄清模式里新建 PRD - 永远不超过总共 5 个问题(同一问题的消歧重试不计为新问题) - 不要问投机性的技术栈问题,除非缺失会阻碍功能清晰性 - 尊重用户的提前终止信号 - 达到配额但仍有高影响未决项,在报告中明确标记"已推迟"并附理由 --- ## 模式三: 扩展 PRD (Extend) ### 目标 向一份已有 PRD **追加一个或多个全新功能**,保持既有用户故事/实体/术语/编号/优先级分布的一致性,不破坏原有结构。 这不是"修正含糊点"(那是澄清模式的职责),而是**扩张范围**。 ### 输入 参数同时包含: - 一个已存在的 PRD 文件路径 - 一段描述新功能的自然语言 ### 执行流程 1. **加载并吃透原 PRD**: 读取整份文件,在内存中提取以下上下文: - 产品/功能的整体目标 - 既有用户故事清单及各自优先级 (P1/P2/P3...) - 功能需求最大编号 (如 `FR-012`) - 成功标准最大编号 (如 `SC-005`) - 关键实体清单及属性 - 术语用法(例如是叫"用户"还是"使用者"、是叫"相册"还是"图集") - 假设与超出范围声明 2. **重复检查**: 判断新功能是否与既有内容重叠: - 如果新功能本质上已经被某个 P1/P2 用户故事覆盖 → **停下来**向用户说明并请求确认(不要偷偷加重复项) - 如果新功能是对既有功能的细化/修正 → **建议改走澄清或修正路径**,不要作为新功能追加 - 如果确实是新功能 → 继续 3. **范围一致性检查**: 对照原 PRD 的"超出范围"章节(如有)。如果新功能明确在超出范围内,提醒用户这是范围扩张,需要确认后再加 4. **解析新功能**: 从描述中提取参与者/操作/数据/约束,按与生成模式相同的标准推断合理默认值 5. **优先级分配**: - 默认新故事的优先级为 `P(current_max + 1)`,即追加到现有最低优先级之后 - 如果新功能明显比某个既有故事更关键(影响核心流程/安全/合规),向用户询问是否调整优先级 — **只问一次,不要反复确认** - 如果用户在描述里明确说了优先级("这个是 P1 的"),直接用 6. **追加用户故事**: 在用户故事章节末尾(边界情况章节之前)新增故事块,遵循原 PRD 的模板格式: ```markdown ### 用户故事 N - [标题] (优先级: PN) ... ``` 7. **追加功能需求**: 从 `FR-(max+1)` 开始递增编号,新需求追加到功能需求列表末尾。**不要**重排或重编已有 FR 8. **按需更新其他章节**: - **关键实体**: 如果新功能引入新实体 → 追加;如果扩展了既有实体的属性 → 修改原实体条目(不要新建重复条目) - **成功标准**: 如果新功能有独立的可衡量目标 → 从 `SC-(max+1)` 开始追加 - **边界情况**: 新功能相关的边缘场景追加到边界情况列表 - **假设**: 如果新功能依赖新的假设 → 追加 - **超出范围**: 如果新功能明确排除某些用法 → 追加 9. **术语统一**: 新内容必须复用原 PRD 已有术语。如果新描述用了不同叫法(比如原文是"相册",新描述是"图集"),自动归一到原文术语 10. **追加 `[NEEDS CLARIFICATION]` 标记**(可选): 仅对新功能的显著模糊点使用,最多 2 个(比整体生成模式更严格,因为整份 PRD 已有上下文可推断) 11. **维护变更日志**: 在 PRD 顶部(`## Clarifications` 之后或之前,统一位置)维护 `## Change Log` 章节,追加一行: ```markdown ## Change Log ### YYYY-MM-DD - Extend - 新增用户故事 N: [标题] (PN) - 新增功能需求: FR-XXX ~ FR-YYY - 新增/更新实体: [实体名] - 新增成功标准: SC-XXX ~ SC-YYY ``` 同日多次扩展时,追加新的子条目到当天的 `### YYYY-MM-DD - Extend` 块下,不要新建重复的日期标题 12. **保存文件**: 原子写回整份 PRD 13. **质量自检**(不落盘): - [ ] 新 FR 编号与既有编号连续,无冲突 - [ ] 新用户故事的"独立测试"描述填写完整 - [ ] 术语与原文一致(无同义词混用) - [ ] 没有重复/覆盖已有需求 - [ ] 每个新 FR 可测试 - [ ] 新 SC 可衡量、技术无关 ### 报告 向用户报告: - PRD 文件路径 - 本次新增内容清单(故事/FR/SC/实体/假设数量) - 分配的优先级及理由 - 遗留的 `[NEEDS CLARIFICATION]`(如有) - 如果扩展使原 PRD 的某些声明需要更新(比如"超出范围"应当删除某项),明确列出**建议用户后续处理的事项**,不要自己静默修改这些边界 - 建议下一步: "可运行澄清模式补全新功能的细节" ### 行为规则 - **不重排已有内容**: 所有既有用户故事、FR、SC、实体的顺序和编号保持不变 - **不覆盖已有内容**: 除非扩展确实使原声明失效(例如新功能让原"超出范围"条目作废),此时需明确在报告中提示用户 - **不跨模式混用**: 扩展模式只负责追加;如果用户在扩展过程中提到既有内容的模糊点,记录下来并建议在扩展完成后运行澄清模式处理 - **单次扩展可包含多个相关功能**: 如果用户描述的是一组相关子功能(例如"加分享功能,包括生成链接、设置过期时间、查看分享记录"),作为一个扩展会话处理,可以产出多个用户故事,但它们应围绕同一个业务主题 --- ## 通用规则 - **语言**: 除非用户明确要求英文,PRD 内容一律用中文撰写 - **无 git 集成**: 不创建分支、不 commit、不调用 git 命令 - **不执行任何脚本**: 所有文件操作直接用 Write/Edit/Read/Bash mkdir 完成 - **关注 What/Why**: 避免描述 How(技术栈、实现细节、框架选型) - **为业务相关方写**: 用通俗语言,而不是开发者术语 - **不要**在 PRD 中嵌入任何检查清单章节(质量清单只用于自检,不落盘)


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)