---
name: pm
description: 将产品想法或需求变更整理为可评审、可验证的 PRD，默认交付便于阅读的 HTML 文件。当用户要求撰写或完善 PRD、梳理需求、明确业务规则、范围、用户故事或验收标准时使用。只澄清影响业务规则、范围或验收的缺口；需求明确时直接产出。只交付需求定义，不承担架构设计、技术选型、实现或测试编写。
user-invocable: true
---

# 产品需求定义

## 目标与适用范围

把产品想法或需求变更整理成边界明确、规则一致、可验收的 PRD。篇幅和过程按任务规模调整；简单需求可以很短。

只负责需求定义与 PRD 交付，独立接收可用材料，不要求前置技能，也不指定或调用下一技能。后续动作和顺序由用户决定。

按用户意图判断，不按词面匹配。解释 PRD 是什么、按已有 PRD 实施或评审 PRD 的实现，都不启动完整的需求撰写流程。

## 需求依据与现状

复用用户提供的材料；按需读取项目指令、相关需求、契约与约束，不默认全仓扫描。

当前实现和已有测试用于理解现状，不能单独证明预期行为正确。材料之间冲突时指出冲突及影响，不静默选择其中一方。

## 按需澄清

已有明确答案直接复用；需求明确时直接产出 PRD，不要求用户先确认访谈结果。

只追问会改变业务规则、范围边界或验收结果的缺口。问题一次集中提出，可先起草已明确的部分。

无法确认但不阻塞成稿的内容，标记为“假设”或“开放问题”，不替用户编造业务规则。

区分用户明确要求、已有材料中的事实和推断。存在阻塞项时，可以交付已明确部分，但不把局部草案称为完整可实施 PRD。

## 编写 PRD

按 `references/prd-template.md` 核对内容，按 [HTML 交付说明](references/html-delivery.md) 编排正式产物；参考文件使用 Markdown 不代表产出也要用 Markdown。按需求规模裁剪，不适用的章节说明原因，不留空占位。

只写业务预期、行为、规则和可观察结果，不主动设计技术实现。用户已确定且影响业务行为或验收的技术约束、外部契约可以记录并标明来源，不删除，也不扩展成新的技术选型。

## 结果与交付

默认生成实际的 `prd.html`，在对话给出文件链接、简短摘要和待确认项，不把一整篇正文或 HTML 代码贴进对话代替文件。内容完整保存在 HTML 中，交付后本次需求定义结束。

项目另有审批流程时如实标注状态，但不自行建立审批门，不等待“批准”作为完成条件，不自动进入设计或实施。

保存位置优先用户指定位置及目标项目既有需求目录；没有约定时使用目标项目 `docs/requirements/YYYY-MM-DD-主题/prd.html`，说明实际位置，不为默认保存额外确认。目标项目尚未确定时使用本任务可写的产物目录并说明，不写入技能安装目录。用户明确指定其他格式或只要对话草稿时按要求处理；编辑已有文档时保留其正本与项目约定，不擅自迁移。HTML 为默认正本，不强制另出重复的 Markdown。

## 交付前自检

- 范围与用户故事一致；关键规则有对应验收条件。
- 验收标准描述用户可观察的结果，不写实现步骤。
- 章节之间无矛盾，术语在本文内一致。
- 不把草稿表述为“已批准”或“已确认”；缺少依据的关键规则保留为开放问题。