前端设计
- 作者仓库星标 330
- 许可证 MIT
- 作者更新于 实时读取
- 作者仓库 claude-skill-registry
- 领域
- 数据
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 94 / 100 · 已通过审计
- 作者 / 版本 / 许可
- @majiayu000 · MIT
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 即装即用
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- Bun
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
---
name: pd
description: 通过对话式交互生成产品需求文档（PRD）。创建包含用户故事、质量门禁和验收标准的结构化 PRD。当用户希望创建 PRD、规划功能、编写需求、写规格说明，或提到「pd」「产品设计」「需求」「用户…
category: 数据
runtime: Bun
---
# pd 输出预览
## PART A: 任务判断
- 适用问题：表格、CSV、数据集、指标或分析流程。
- 输入要求：目标材料、限制条件、期望输出和验收方式。
- 证据边界：围绕“任务说明 / 步骤 1：澄清问题（迭代进行） / 问题格式示例：”读取原文规则，不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断：确认你的需求是否属于表格、CSV、数据集、指标或分析流程，并标出输入、限制和预期结果。
- **02** 执行计划：优先按“任务说明 / 步骤 1：澄清问题（迭代进行） / 问题格式示例：”拆成步骤，说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果：给出可复制的命令、文件改动、检查清单或内容草稿，并说明如何继续迭代。
- **04** 风险边界：结合 读取文件、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件；主要在本地完成；通常不需要额外 API Key。
- 先小样例验证，再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。原文没有稳定的斜杠命令要求。安装验证后通常全局生效，直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是：读取文件、写入/修改文件。
先用一个小任务确认它会围绕“任务说明 / 步骤 1：澄清问题（迭代进行） / 问题格式示例：”工作；涉及文件或命令时，先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作；如果输出泛泛而谈，就补充输入、边界和验收标准后重跑。
---
name: pd
description: 通过对话式交互生成产品需求文档（PRD）。创建包含用户故事、质量门禁和验收标准的结构化 PRD。当用户希望创建 PRD、规划功能、编写需求、写规格说明，或提到「pd」「产品设计」「需求」「用户…
category: 数据
source: majiayu000/claude-skill-registry
---
# pd
## 什么时候使用
- 把数据处理方向的常用动作沉淀成 Agent 可调用的技能 适合处理表格、CSV、指标、数据集、分析和可视化报告，核心价值是把输入、判断、执行、验证和交付边界固定下来，避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步…
- 面向表格、CSV、数据集、指标或分析流程，优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「任务说明 / 步骤 1：澄清问题（迭代进行） / 问题格式示例：」组织步骤，不把推断写成作者事实。
- 读取文件、写入/修改文件；主要在本地完成；通常不需要额外 API Key。
- 先跑小样例，确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown，不编造命令、平台或依赖。作者原文负责流程事实；仓库文件负责来源和命令；流狐只补充适用场景、限制和质量判断。
skill "pd" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> 任务说明 / 步骤 1：澄清问题（迭代进行） / 问题格式示例：
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Bun | 读取文件、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
}PD - 产品需求文档生成器
创建面向 AI 智能体执行而优化的结构化产品需求文档。
任务说明
- 接收用户的功能描述
- 提出 3～5 个关键澄清问题（带字母选项），每次一组
- 务必询问质量门禁（须通过哪些命令）
- 每次回答后，如需要可继续追问（自适应探索）
- 在上下文足够时生成结构化 PRD
- 用
[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。先问几个问题：
主要目标是什么？ A. 减少长时间使用的眼疲劳 B. 跟随系统主题偏好 C. 提供视觉自定义 D. 其他
设置是否需要持久化？ A. 是，保存到配置文件 B. 否，仅当前会话 C. 跟随系统偏好
用户： 1A, 2A
助手： 好的，再问两个：
哪些组件需要支持暗色模式？ A. 所有组件 B. 仅主视图 C. 主视图 + 设置 D. 其他
每个故事须通过哪些质量命令？ 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 中注明所做假设
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核