to-prd

Name: to-prd
Author: BlueprintOS

24stars2forks

How to install to-prd?

blueprintos/analysis-to-delivery/to-prd

$npx -y skills add BlueprintOS/analysis-to-delivery --skill to-prd

Installs into the current project.

Summary

生成产品需求文档(PRD)— 含用户故事、功能需求、非功能需求、验收标准。需将产品需求正式化、向设计与开发团队交接时调用本 skill,输出三格式产物(源 / HTML / DOCX)。

Files · 1

View on GitHub

SKILL.md

1	# To-PRD — 产品需求文档生成
2
3	## Contract
4
5	- 输入: 已签字的 BRD、合规评审、测试用例、字段对齐分析
6	- 输出: `05-产品需求文档 PRD.md`、可选 `05-PRD.html`、可选 `05-PRD.docx`、可选 Figma 设计文档
7	- 门控: PRD 必备章节齐全;验收标准已签字;字段映射与知识库核对
8	- Required rules: `stage-gate`, `no-field-guessing`, `doc-numbering`, `goal-boundary`
9	- Required paths: `knowledge-path`, `doc-naming-path`
10	- 下一步: `/dev-design`
11
12	## 适用场景
13
14	- BRD + 合规评审 + 测试用例已通过
15	- 需要把业务需求翻译成产品视角
16	- 设计/开发团队需要可执行的需求输入
17
18	## 流程步骤
19
20	### 1. 加载模板
21
22	- `templates/PRD.md`(8 节必备章节)
23
24	### 2. 三格式输出
25
26	\| 格式 \| 用途 \| 生成方式 \|
27	\|---\|---\|---\|
28	\| Markdown \| 源文件、版本管理 \| 手工编写 \|
29	\| HTML \| 浏览器阅读、分享 \| pandoc + `scripts/postprocess_prd_html.py` \|
30	\| DOCX \| Word 阅读、批注 \| pandoc \|
31
32	### 3. 填充内容
33
34	按 PRD 模板逐节生成:
35
36	\| 章节 \| 内容来源 \|
37	\|---\|---\|
38	\| 一、产品概述 \| BRD §1 \|
39	\| 二、用户故事 \| BRD §2 角色 + 业务场景 \|
40	\| 三、功能需求 \| BRD §4 + 测试用例(用作验收) \|
41	\| 四、非功能需求 \| BRD §7 \|
42	\| 五、数据需求 \| BRD §5 + 字段对齐分析 \|
43	\| 六、合规要求 \| 04-合规评审.md \|
44	\| 七、验收标准 \| 07-测试用例设计.md \|
45	\| 八、风险与依赖 \| BRD §8 \|
46
47	### 4. 关键纪律
48
49	- 字段名必须与知识库定义一致
50	- 业务同义不同名需在 PRD 注释中显式标注("业务上称为 X = 知识库定义的 Y")
51	- 严禁自行发明字段
52	- 用户故事格式:`As an <actor>, I want a <feature>, so that <benefit>`
53
54	### 5. Figma 设计文档引用(如适用)
55
56	- 简单需求(加字段/调规则)→ 跳过
57	- 中等需求(新增功能/页面改造)→ 需要 Figma 文档
58	- 复杂需求(跨模块/多角色/算法介入)→ 必须 Figma 文档
59
60	## 输出
61
62	- `05-PRD.md`(Markdown 源)
63	- `05-PRD.html`(可选,后处理)
64	- `05-PRD.docx`(可选)
65	- `Figma设计文档_{功能名}_{端}.md`(可选,不受编号约束)
66
67	## 调用的 rule
68
69	- `rules/no-field-guessing` — 字段名必须查知识库
70	- `rules/doc-numbering` — 文档编号 05
71
72	## 结束条件
73
74	- [ ] PRD 8 个必备章节齐
75	- [ ] §七验收标准签字
76	- [ ] 字段映射表通过 `field-alignment-check.py`
77	- [ ] 三格式产物存在(可选 HTML/DOCX)
78	- [ ] 用户签字进入 `/dev-design`
79
80	## 反模式
81
82	- ❌ PRD 8 章节缺一 — `prd-check.py --strict` 直接 fail(一~八必须齐)
83	- ❌ §七验收标准未被白名单签字 — 必须 4 句之一(我已全部确认,可以进入下一步 / 确认通过,进入 dev-design / 全部完成,继续 / approved, proceed to next stage)
84	- ❌ §二用户故事只列 P0 — P0/P1/P2 三档必须都有,否则后续排期无法决策
85	- ❌ §五数据需求不引用 03-数据模型设计 — 必须明确"参考 03-数据模型设计.md §X"
86	- ❌ §六合规要求不引用 04-合规评审 — 必须明确"参考 04-合规评审.md §X"
87	- ❌ §三功能需求跳过异常处理 — 3.1.X 异常处理表格必填(异常/提示/处理三列)
88	- ❌ §八风险与依赖无缓解措施 — 每条风险必须配缓解 + 责任方

People who liked this also viewed

6 picks

Type

to-prd

24stars2forks

View on GitHub

How to install to-prd?

blueprintos/analysis-to-delivery/to-prd

$npx -y skills add BlueprintOS/analysis-to-delivery --skill to-prd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# To-PRD — 产品需求文档生成
2
3	## Contract
4
5	- 输入: 已签字的 BRD、合规评审、测试用例、字段对齐分析
6	- 输出: `05-产品需求文档 PRD.md`、可选 `05-PRD.html`、可选 `05-PRD.docx`、可选 Figma 设计文档
7	- 门控: PRD 必备章节齐全;验收标准已签字;字段映射与知识库核对
8	- Required rules: `stage-gate`, `no-field-guessing`, `doc-numbering`, `goal-boundary`
9	- Required paths: `knowledge-path`, `doc-naming-path`
10	- 下一步: `/dev-design`
11
12	## 适用场景
13
14	- BRD + 合规评审 + 测试用例已通过
15	- 需要把业务需求翻译成产品视角
16	- 设计/开发团队需要可执行的需求输入
17
18	## 流程步骤
19
20	### 1. 加载模板
21
22	- `templates/PRD.md`(8 节必备章节)
23
24	### 2. 三格式输出
25
26	\| 格式 \| 用途 \| 生成方式 \|
27	\|---\|---\|---\|
28	\| Markdown \| 源文件、版本管理 \| 手工编写 \|
29	\| HTML \| 浏览器阅读、分享 \| pandoc + `scripts/postprocess_prd_html.py` \|
30	\| DOCX \| Word 阅读、批注 \| pandoc \|
31
32	### 3. 填充内容
33
34	按 PRD 模板逐节生成:
35
36	\| 章节 \| 内容来源 \|
37	\|---\|---\|
38	\| 一、产品概述 \| BRD §1 \|
39	\| 二、用户故事 \| BRD §2 角色 + 业务场景 \|
40	\| 三、功能需求 \| BRD §4 + 测试用例(用作验收) \|
41	\| 四、非功能需求 \| BRD §7 \|
42	\| 五、数据需求 \| BRD §5 + 字段对齐分析 \|
43	\| 六、合规要求 \| 04-合规评审.md \|
44	\| 七、验收标准 \| 07-测试用例设计.md \|
45	\| 八、风险与依赖 \| BRD §8 \|
46
47	### 4. 关键纪律
48
49	- 字段名必须与知识库定义一致
50	- 业务同义不同名需在 PRD 注释中显式标注("业务上称为 X = 知识库定义的 Y")
51	- 严禁自行发明字段
52	- 用户故事格式:`As an <actor>, I want a <feature>, so that <benefit>`
53
54	### 5. Figma 设计文档引用(如适用)
55
56	- 简单需求(加字段/调规则)→ 跳过
57	- 中等需求(新增功能/页面改造)→ 需要 Figma 文档
58	- 复杂需求(跨模块/多角色/算法介入)→ 必须 Figma 文档
59
60	## 输出
61
62	- `05-PRD.md`(Markdown 源)
63	- `05-PRD.html`(可选,后处理)
64	- `05-PRD.docx`(可选)
65	- `Figma设计文档_{功能名}_{端}.md`(可选,不受编号约束)
66
67	## 调用的 rule
68
69	- `rules/no-field-guessing` — 字段名必须查知识库
70	- `rules/doc-numbering` — 文档编号 05
71
72	## 结束条件
73
74	- [ ] PRD 8 个必备章节齐
75	- [ ] §七验收标准签字
76	- [ ] 字段映射表通过 `field-alignment-check.py`
77	- [ ] 三格式产物存在(可选 HTML/DOCX)
78	- [ ] 用户签字进入 `/dev-design`
79
80	## 反模式
81
82	- ❌ PRD 8 章节缺一 — `prd-check.py --strict` 直接 fail(一~八必须齐)
83	- ❌ §七验收标准未被白名单签字 — 必须 4 句之一(我已全部确认,可以进入下一步 / 确认通过,进入 dev-design / 全部完成,继续 / approved, proceed to next stage)
84	- ❌ §二用户故事只列 P0 — P0/P1/P2 三档必须都有,否则后续排期无法决策
85	- ❌ §五数据需求不引用 03-数据模型设计 — 必须明确"参考 03-数据模型设计.md §X"
86	- ❌ §六合规要求不引用 04-合规评审 — 必须明确"参考 04-合规评审.md §X"
87	- ❌ §三功能需求跳过异常处理 — 3.1.X 异常处理表格必填(异常/提示/处理三列)
88	- ❌ §八风险与依赖无缓解措施 — 每条风险必须配缓解 + 责任方

People who liked this also viewed

6 picks

Type