Imported from pmYangKun/create-prd-skill (
SKILL.md). Install upstream withnpx skills add pmYangKun/create-prd-skill. Copyright stays with the author.
create-prd
根据用户提供的业务上下文和需求背景，生成结构化的、带有初始内容的 B端 PRD 文档。
支持显式调用（如 /create-prd）和自动触发（当用户明确要求创建、撰写 PRD、需求文档、产品方案或企业系统设计时）。
输入
- 用户提供的业务上下文和需求背景（自由文本、会议纪要、简要描述等均可）
- 或通过
$ARGUMENTS传入的文件路径
如有参数传入，优先作为输入源：
$ARGUMENTS
生成流程
严格按以下顺序执行，不可跳过或调换步骤。
阶段 0：理解上下文与产品定型
- 完整阅读并理解用户提供的所有业务上下文。
- 从用户描述中推断：
- 商业属性：商业化产品 or 企业自研系统
- 功能类型：业务型管理软件 / 工具型软件 / 交易型平台 / 基础服务型
- 用一句话向用户呈现推断结果，请求确认：
根据你的描述，这是一个【{商业属性} × {功能类型}】产品{，简要理由}。我会据此调整 PRD 各章节的侧重点。如有不对请纠正。
- 等待用户确认后再继续。
- 确认后，加载定型参考文件以确定各章节的适配规则：
阶段 1：前置章节（1-9章）
按顺序生成第1至第9章。每完成一章，立即输出该章内容，不要等所有章节完成后再一起输出。
每章加载对应的生成指引：
阶段 2：核心功能需求（第10章）
这是 PRD 中最大、最核心的章节。加载生成指引：
按子章节分段生成：
- 10.1 产品框架概述（系统框架图、数据模型图、业务流程图、状态机图、功能清单）
- 10.2 产品需求详解（逐模块：流程图 → 页面交互 → 业务规则）
- 10.3 异常情况处理方案
阶段 3：后置章节（11-14章）
阶段 4：自检与缺口分析
所有章节生成完毕后，执行轻量自检：
输出规范
文档格式
以单个 Markdown 文档输出 PRD，结构如下：
# {产品/项目名称} PRD
| PRD 审核人 | {待填写} |
| --- | --- |
| 重要性 | {高/中/低} |
| 紧迫性 | {高/中/低} |
| 需求方 | {从上下文推断或标注待填写} |
| PRD 编写人 | {用户姓名或待填写} |
| PRD 提交日期 | {当前日期} |
## PRD 修改记录
| 变更时间 | 变更内容 | 变更提出部门与理由 | 修改人 | 审核人 | 版本号 |
| --- | --- | --- | --- | --- | --- |
| {当前日期} | 初始版本 | — | {编写人} | {待填写} | v1.0 |
---
## 1、项目背景
...（各章节内容）
## 14、待决事项
...
---
## 附：待完善清单
...内容生成规则
- 有信息则生成实质内容：根据用户提供的上下文，尽可能生成具体、有实质内容的初稿。
- 信息不足则标注
[TODO]：对于用户未提供足够信息的部分，用[TODO: 具体需要补充什么]标注，而不是编造内容。 - 区分产品类型：商业化产品与企业自研系统的内容侧重点不同，严格按照产品定型结果调整。
- 理论框架外显：在关键章节中，用简短提示说明所使用的方法论框架，帮助用户理解设计依据。
- 结构化优先：表格、列表、Mermaid 图表优先于大段叙述。
- 图表使用 Mermaid：架构图、流程图、状态机、ER 模型等全部使用 Mermaid 代码块生成，不使用 ASCII 伪图。
图表生成规则
第10章产品框架概述中，以下图表必须使用 Mermaid 语法：
| 图表类型 | Mermaid 语法 | 必须包含 |
|---|---|---|
| 应用架构图 | graph TB + subgraph 分层 |
用户层、接入层、业务服务层、数据层、外部系统 |
| ER 数据模型 | erDiagram |
所有核心实体+关系+关键属性（PK/FK/状态） |
| 业务流程图 | flowchart TD |
主流程+关键分支+异常路径，关键节点着色 |
| 状态机图 | stateDiagram-v2 |
正常+异常路径，附 note 说明约束 |
注意事项：
- Mermaid 图后面附对应的明细表格作为补充说明（如状态机图+状态转换表）
- 图表内节点文字用
<br/>换行，保持简洁 - 具体模板和示例见第10章生成指引文件
逐章输出规则
- 每完成一章立即输出，不要等所有章节完成后再一起输出。
- 每章必须有清晰的章节标题，与 PRD 模板结构一致。
- 结构化数据（字段、权限、规则等）优先使用表格。
- 使用
> 💡 方法论提示：引用块来呈现所应用的理论框架。 - 不确定的内容用
[TODO]标注，并说明需要补充什么信息。
工作风格
- 目标是生成一份可用的 PRD 脚手架，加速产品经理的工作，而不是替代其判断。
- 用户上下文充分时，尽量具体和有实质内容；信息不足时，坦诚标注缺口。
- 保持专业的 PRD 写作风格：精确、结构化、无歧义。
- 根据用户提供的上下文丰富度调整深度——一段话的上下文生成轻量 PRD，详细上下文生成丰富 PRD。
- 如果用户提供的上下文非常有限，生成结构框架并附带指引说明，主动询问哪些补充信息有助于充实关键章节。