陌讯skills聚合平台

pd

📁 kunhai-88/skills 📅 Jan 25, 2026
4
总安装量
3
周安装量
#48859
全站排名
安装命令
npx skills add https://github.com/kunhai-88/skills --skill pd

Agent 安装分布

cursor 2
codex 2
claude-code 2
antigravity 2
windsurf 1

Skill 文档

PD – 产品需求文档生成器

创建面向 AI 智能体执行而优化的结构化产品需求文档。

任务说明

  1. 接收用户的功能描述
  2. 提出 3～5 个关键澄清问题（带字母选项），每次一组
  3. 务必询问质量门禁（须通过哪些命令）
  4. 每次回答后，如需要可继续追问（自适应探索）
  5. 在上下文足够时生成结构化 PRD
  6. 用 [PRD]...[/PRD] 标记包裹 PRD 输出，便于解析

重要： 不要开始实现，只生成 PRD。

步骤 1：澄清问题（迭代进行）

每次只问一组问题。每次回答应影响下一组问题。关注：

  • 问题/目标：解决什么问题？
  • 核心功能：关键行为有哪些？
  • 范围/边界：不应包含哪些内容？
  • 成功标准：如何判断完成？
  • 集成方式：与现有功能如何配合？
  • 质量门禁：每个用户故事须通过哪些命令？（必问）

问题格式示例：

1. 该功能的主要目标是什么？
 A. 改善用户入门体验
 B. 提高用户留存
 C. 降低支持负担
 D. 其他：[请说明]

2. 目标用户是谁？
 A. 仅新用户
 B. 仅现有用户
 C. 所有用户
 D. 仅管理员

这样用户可以用「1A, 2C」快速回答。

质量门禁问题（必问）

务必询问质量门禁——它们因项目而异：

每个用户故事须通过哪些质量命令？
 A. pnpm typecheck && pnpm lint
 B. npm run typecheck && npm run lint
 C. bun run typecheck && bun run lint
 D. 其他：[请说明你的命令]

对于 UI 故事，是否需要包含浏览器验证？
 A. 是，用 dev-browser 技能做可视化验证
 B. 否，自动化测试即可

自适应提问

每次回答后，决定：

  • 继续追问（若答案显示复杂度）
  • 问新方面（若当前已清晰）
  • 生成 PRD（若上下文已足够）

通常需要 2～4 轮问题。

步骤 2：PRD 结构

按以下章节生成 PRD：

1. 引言/概述

简要描述功能及其解决的问题。

2. 目标

具体、可衡量的目标（列表）。

3. 质量门禁

关键： 列出每个用户故事必须通过的命令。

## 质量门禁

以下命令对每个用户故事必须通过：
- `pnpm typecheck` - 类型检查
- `pnpm lint` - 代码规范

对 UI 故事，还需包含：
- 使用 dev-browser 技能在浏览器中验证

该章节会被转换工具提取，并附加到每个故事的验收标准中。

4. 用户故事

每个故事需包含：

  • 标题：简短描述性名称
  • 描述：「作为 [用户]，我希望 [功能]，以便 [收益]」
  • 验收标准：可验证的「完成」检查清单

每个故事应足够小，能在一次聚焦的 AI 智能体会话中完成。

格式：

### US-001: [标题]
**描述：** 作为 [用户]，我希望 [功能]，以便 [收益]。

**验收标准：**
- [ ] 具体可验证的标准
- [ ] 另一条标准

说明： 不要在单个故事的验收标准里写质量门禁命令——它们在「质量门禁」章节统一定义，转换时自动应用到各故事。

重要：

  • 验收标准必须可验证，不能模糊
  • 「工作正常」不好
  • 「删除前按钮显示确认对话框」好
  • 每个故事应可独立完成

5. 功能需求

按编号列出具体功能：

  • 「FR-1：系统必须允许用户……」
  • 「FR-2：当用户点击 X 时，系统必须……」

表述明确、无歧义。

6. 非目标（不在范围内）

本功能不包含的内容。对控制范围很关键。

7. 技术考量（可选）

  • 已知约束或依赖
  • 与现有系统的集成点
  • 性能要求

8. 成功指标

如何衡量成功？

9. 待解决问题

剩余问题或需进一步澄清的部分。

面向 AI 智能体的写作

PRD 将由 AI 编程智能体执行，因此：

  • 表述明确、无歧义
  • 用户故事要小（一次会话可完成）
  • 验收标准尽量可机器验证
  • 若已知，写出具体文件路径
  • 引用项目现有代码模式

输出格式

关键： 最终 PRD 用以下标记包裹，便于解析：

[PRD]
# PRD: 功能名称

## 概述
...

## 质量门禁
...

## 用户故事
...
[/PRD]

文件命名： 保存为 ./tasks/prd-[功能名].md 或建议合适路径。

示例对话流程

用户： 为添加暗色模式创建一个 PRD

助手： 好的，我来帮你做暗色模式的 PRD。先问几个问题：

  1. 主要目标是什么？ A. 减少长时间使用的眼疲劳 B. 跟随系统主题偏好 C. 提供视觉自定义 D. 其他

  2. 设置是否需要持久化？ A. 是，保存到配置文件 B. 否，仅当前会话 C. 跟随系统偏好

用户： 1A, 2A

助手： 好的，再问两个：

  1. 哪些组件需要支持暗色模式？ A. 所有组件 B. 仅主视图 C. 主视图 + 设置 D. 其他

  2. 每个故事须通过哪些质量命令？ A. pnpm typecheck && pnpm lint B. npm run typecheck && npm run lint C. bun run typecheck D. 其他：[请说明]

用户： 3A, 4A

助手： 可以，正在生成 PRD。

[PRD]

PRD: 暗色模式

概述

添加暗色模式以减轻长时间使用的眼疲劳。功能将覆盖所有组件，并将用户偏好在配置文件中持久化。

目标

  • 在弱光环境下提供舒适的浏览体验
  • 主题偏好跨会话持久化
  • 对所有组件应用一致的样式

质量门禁

以下命令对每个用户故事必须通过：

  • pnpm typecheck – 类型检查
  • pnpm lint – 代码规范

用户故事

US-001: 添加主题配置

描述： 作为用户，我希望设置首选主题（亮色/暗色），以便跨会话持久化。

验收标准：

  • 在配置 schema 中增加 theme 字段
  • 支持取值：”light”、”dark”、”system”
  • 默认 “light” 以保持向后兼容

US-002: 创建暗色主题配色

描述： 作为用户，我希望有柔和对比的暗色主题，减轻用眼负担。

验收标准：

  • 用灰色调定义暗色配色（非纯黑）
  • 保证足够对比度（WCAG AA）
  • 颜色适用于所有 UI 状态

US-003: 对所有组件应用主题

描述： 作为用户，我希望所有组件遵循我的主题偏好。

验收标准：

  • 头部组件使用主题色
  • 主视图使用主题色
  • 设置面板使用主题色
  • 弹窗使用主题色

US-004: 在设置中添加主题切换

描述： 作为用户，我希望在设置中切换主题。

验收标准：

  • 设置视图中可见主题选项
  • 修改立即生效，无需重启
  • 修改持久化到配置文件

功能需求

  • FR-1：主题设置须能从配置文件读取
  • FR-2：启动时须应用主题
  • FR-3：主题变更须立即生效
  • FR-4：所有文本在两种主题下均须保持可读

非目标

  • 系统主题自动检测（后续增强）
  • 除亮/暗外的自定义配色
  • 按组件的主题覆盖

技术考量

  • 若有现成主题能力则复用
  • 考虑为 React 组件建 ThemeContext
  • 主题切换时尽量减少重渲染

成功指标

  • 所有组件在暗色模式下正确渲染
  • 无无障碍对比度问题
  • 主题跨会话持久化

待解决问题

  • v2 是否应自动检测系统主题偏好？ [/PRD]

检查清单

输出 PRD 前确认：

  • 已提出带字母选项的澄清问题
  • 已询问质量门禁（必做）
  • 需要时已做追问
  • 已包含「质量门禁」章节及项目专属命令
  • 用户故事足够小且可独立完成
  • 用户故事中未包含质量门禁命令（见质量门禁章节）
  • 功能需求已编号且无歧义
  • 非目标章节界定了清晰范围
  • PRD 已用 [PRD]...[/PRD] 包裹

异常处理

若用户回答不清或不完整：

  • 礼貌请求澄清
  • 提出换一种问法
  • 给出有效回答示例

若用户希望跳过问题：

  • 允许跳过可选问题
  • 质量门禁信息始终必填
  • 在 PRD 中注明所做假设
GitHub 仓库 ↗ ← 返回陌讯 Skills 聚合平台
本页面由 陌讯 Skills 聚合平台 收录整理，数据定期更新。