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

# 产品需求定义

## 目标与适用范围

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

本技能只负责需求定义与 PRD 交付；需求之外的判断和动作由用户或调用方决定。

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

## 需求依据与现状

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

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

## 按需澄清

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

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

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

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

## 编写 PRD

按 `references/prd-template.md` 组织，按需求规模裁剪：必需的是信息，不是固定章节数量；不适用的章节说明原因，不留空占位。

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

## 结果与交付

给出 PRD 内容、已采用的假设和待确认项。交付后本次需求定义结束。

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

默认在对话中交付。用户要求保存，或项目指令文件（`AGENTS.md`、`CLAUDE.md` 等）有明确位置约定时，按约定保存；两者都没有时询问一次，不自行创建路径。

## 交付前自检

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