pm · diff
git:20261027.d64c4c5 to git:20261029.640ec95
5 added, 5 removed. Audit A to A.
---
name: pm
- description: 将产品想法或需求变更整理为可评审、可验证的 PRD。当用户要求撰写或完善 PRD、梳理需求、明确业务规则、范围、用户故事或验收标准时使用。只澄清影响业务规则、范围或验收的缺口；需求明确时直接产出。只交付需求定义，不承担架构设计、技术选型、实现或测试编写。
+ description: 将产品想法或需求变更整理为可评审、可验证的 PRD，默认交付便于阅读的 HTML 文件。当用户要求撰写或完善 PRD、梳理需求、明确业务规则、范围、用户故事或验收标准时使用。只澄清影响业务规则、范围或验收的缺口；需求明确时直接产出。只交付需求定义，不承担架构设计、技术选型、实现或测试编写。
user-invocable: true
---
# 产品需求定义
## 目标与适用范围
把产品想法或需求变更整理成边界明确、规则一致、可验收的 PRD。篇幅和过程按任务规模调整；简单需求可以很短。
- 本技能只负责需求定义与 PRD 交付；需求之外的判断和动作由用户或调用方决定。
+ 只负责需求定义与 PRD 交付，独立接收可用材料，不要求前置技能，也不指定或调用下一技能。后续动作和顺序由用户决定。
按用户意图判断，不按词面匹配。解释 PRD 是什么、按已有 PRD 实施或评审 PRD 的实现，都不启动完整的需求撰写流程。
## 需求依据与现状
复用用户提供的材料；按需读取项目指令、相关需求、契约与约束，不默认全仓扫描。
当前实现和已有测试用于理解现状，不能单独证明预期行为正确。材料之间冲突时指出冲突及影响，不静默选择其中一方。
## 按需澄清
已有明确答案直接复用；需求明确时直接产出 PRD，不要求用户先确认访谈结果。
只追问会改变业务规则、范围边界或验收结果的缺口。问题一次集中提出，可先起草已明确的部分。
无法确认但不阻塞成稿的内容，标记为“假设”或“开放问题”，不替用户编造业务规则。
区分用户明确要求、已有材料中的事实和推断。存在阻塞项时，可以交付已明确部分，但不把局部草案称为完整可实施 PRD。
## 编写 PRD
- 按 `references/prd-template.md` 组织，按需求规模裁剪：必需的是信息，不是固定章节数量；不适用的章节说明原因，不留空占位。
+ 按 `references/prd-template.md` 核对内容，按 [HTML 交付说明](references/html-delivery.md) 编排正式产物；参考文件使用 Markdown 不代表产出也要用 Markdown。按需求规模裁剪，不适用的章节说明原因，不留空占位。
只写业务预期、行为、规则和可观察结果，不主动设计技术实现。用户已确定且影响业务行为或验收的技术约束、外部契约可以记录并标明来源，不删除，也不扩展成新的技术选型。
## 结果与交付
- 给出 PRD 内容、已采用的假设和待确认项。交付后本次需求定义结束。
+ 默认生成实际的 `prd.html`，在对话给出文件链接、简短摘要和待确认项，不把一整篇正文或 HTML 代码贴进对话代替文件。内容完整保存在 HTML 中，交付后本次需求定义结束。
项目另有审批流程时如实标注状态，但不自行建立审批门，不等待“批准”作为完成条件，不自动进入设计或实施。
- 默认在对话中交付。用户要求保存，或项目指令文件（`AGENTS.md`、`CLAUDE.md` 等）有明确位置约定时，按约定保存；两者都没有时询问一次，不自行创建路径。
+ 保存位置优先用户指定位置及目标项目既有需求目录；没有约定时使用目标项目 `docs/requirements/YYYY-MM-DD-主题/prd.html`，说明实际位置，不为默认保存额外确认。目标项目尚未确定时使用本任务可写的产物目录并说明，不写入技能安装目录。用户明确指定其他格式或只要对话草稿时按要求处理；编辑已有文档时保留其正本与项目约定，不擅自迁移。HTML 为默认正本，不强制另出重复的 Markdown。
## 交付前自检
- 范围与用户故事一致；关键规则有对应验收条件。
- 验收标准描述用户可观察的结果，不写实现步骤。
- 章节之间无矛盾，术语在本文内一致。
- 不把草稿表述为“已批准”或“已确认”；缺少依据的关键规则保留为开放问题。