技能使用指南

dot-ai-prd-create（AI-PRD创建技能）Skill 是什么？

dot-ai-prd-create 技能用一条斜杠命令把产品想法变成可追踪的 PRD：自动创建带 PRD 标签的 GitHub 问题、按问题 ID 生成 prds/ 目录下的需求文档、规划 5-10 个可验证里程碑并联动 ROADMAP.md，收尾还给出立即开工或提交推送两条路径。本文讲清安装前提、九步使用流程、竞品对比与常见问题，帮研发团队把需求管理沉淀进仓库。

AI-PRD创建技能Skilldot-ai-prd-create
8 个章节 约 12 分钟阅读 AI 智能生成

AI-PRD创建技能：用一条斜杠命令，把产品想法变成可追踪的 PRD 与 GitHub 问题

  • 文档优先：技能把「产品需求文档（PRD）」当作项目管理的核心载体，而不是写一次就丢的 Word 附件。
  • 双产物结构：一次调用同时产出「GitHub 问题（Issue）」+「PRD 文件」，问题给概念、文档给细节，两者互相链接。
  • 先建问题再建文件：技能明确规定必须先用 GitHub 问题拿到问题 ID，再用该 ID 命名 prds/[问题-id]-[功能名称].md，从流程上解决「先有鸡还是先有蛋」的命名难题。
  • 里程碑而非任务清单：要求把实施计划压缩成 5-10 个「有意义、可测试、以用户为中心」的里程碑，避免陷入「改 README、补拼写错误」这类微任务。
  • 收尾可执行：PRD 完成后直接给出「立即开工」或「提交推送稍后再做」两个编号选项，并附带对应的 Git 命令与后续斜杠命令。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：AI-PRD创建技能Skill 技能英文名：dot-ai-prd-create 技能 ID：11174

它要解决的问题很具体：产品想法通常散落在聊天记录、会议纪要和个人脑子里，等到要开发时才发现「需求没写清、进度没法定、文档和代码对不上」。这个技能把 PRD 创建变成一条可复用的斜杠命令工作流——你只需描述功能想法，技能会按固定流程带你产出 GitHub 问题与 PRD 文件，并规划里程碑与后续动作。

「一键安装」的思路与步骤（技能详情未提供具体安装命令与地址，以下为通用做法，具体入口与命令以官方说明为准）：

  1. 准备运行环境：该技能以斜杠命令形式被调用（详情标注「用户可调用: true」），因此需要在你日常使用的 AI 编程助手 / CLI 环境中安装技能。
  2. 安装技能本体：在所用平台的技能市场或技能包管理中，按技能英文名 dot-ai-prd-create 或技能 ID 11174 检索并安装；若平台支持配置文件方式，按官方文档写入技能清单。
  3. 准备 GitHub 侧前提：技能依赖 GitHub CLI（gh）执行创建问题、创建标签等操作。请先完成安装并登录。若执行中提示「命令未找到」，技能会提示你需要 GitHub CLI，并提供官方安装地址：https://cli.github.com/
  4. 准备仓库前提：目标仓库需要有创建 Issue、创建标签、提交并推送的权限，且仓库中允许存在 prds/ 目录（首次创建时会新建）。
  5. 验证是否生效：安装后发起一次技能调用，若技能能主动询问「请描述你的功能想法」并进入概念讨论环节，说明已生效；也可先手动执行 gh 相关命令确认环境就绪。

2. 该技能的主要功能和特点

  • 双文档体系：同时生成「简短、不可变的 GitHub 问题」与「详细的 PRD 文件」，问题描述概念与优先级，PRD 承载里程碑与实施计划。
  • 强制正确的创建顺序：步骤 2-4 必须按「建问题 → 拿 ID → 建 PRD 文件 → 回填链接」的严格顺序执行，避免文件名无法确定的问题。
  • 可发现性设计：创建问题后自动添加「PRD」标签，方便后续在 Issue 列表中筛选所有需求；若标签不存在，会用 gh label create "PRD" --description "产品需求文档" --color 0052CC 先创建标签再重试。
  • 结构化引导提问：内置 10 个 PRD 规划问题（问题理解、用户影响、技术范围、文档影响、集成点、成功标准、实施阶段、风险评估、依赖项、验证策略），把模糊想法问成可执行需求。
  • 里程碑纪律：明确「5-10 个主要里程碑」原则，并给出正反例——「核心功能实施并工作」「新功能测试通过」「文档完成，遵循现有模式」是合格里程碑，「更新 README.md」「为函数 X 编写测试」属于应避免的微任务。
  • 按需覆盖测试与文档：当项目有测试套件时建议加入测试覆盖里程碑；当功能面向用户时建议加入文档里程碑。
  • 联动路线图：若 docs/ROADMAP.md 存在，会按优先级把新功能写入短期 / 中期 / 长期对应段落，格式为 - [简要功能描述] (PRD #[问题-id])。
  • 收尾闭环：创建完成后展示「1 立即开工 / 2 提交推送稍后处理」两个选项，提交时使用 [skip ci] 标志避免无意义 CI 运行，并在提交信息中包含问题编号便于追溯。

和「直接让 AI 写一份 PRD」相比，它的差异在于流程约束：普通工具只产出文本，这个技能产出的是仓库里可追溯、可链接、可排期的资产。

3. 如何使用该技能？

  1. 触发技能：在已安装技能的环境中调用该斜杠命令，进入「创建 PRD」流程。
  2. 描述功能概念：按提示说明你的功能想法。示例输入：

    「我想给命令行工具加一个批量导出功能，让用户可以一次性把多个项目导出为 JSON，方便做数据迁移。」 技能会围绕问题、用户影响、技术范围继续追问，直到歧义消除。

  3. 等待 GitHub 问题被创建：技能会立即创建问题以获取问题 ID，并自动加上「PRD」标签。此时问题正文使用初始模板：功能名称、1-2 句问题描述、1-2 句解决方案概述、「详细PRD：PRD文件创建后添加」、优先级（高/中/低）。
  4. 生成 PRD 文件：技能以实际问题 ID 命名文件，路径为 prds/[问题-id]-[功能名称].md。
  5. 回填 PRD 链接：问题正文中的「详细PRD」会被替换为指向 prds/[实际-问题-id]-[功能名称].md 的链接。
  6. 逐节讨论并填写 PRD：技能按模板逐节推进，重点落在项目管理、里程碑跟踪与实施计划上，文档更新本身也被建议纳入实施里程碑。
  7. 定义里程碑：与技能一起把实施计划收敛为 5-10 个可验证里程碑，示例输出形态：
    • [ ] 核心功能实施并工作
    • [ ] 新功能测试通过（项目有测试套件时）
    • [ ] 文档完成，遵循现有模式（面向用户的功能）
    • [ ] 与现有系统集成工作
    • [ ] 功能准备用户测试
  8. 同步路线图：若存在 docs/ROADMAP.md，按优先级写入对应时间段。
  9. 选择下一步：技能输出编号选项。选 1 会先提交推送 PRD，再提示运行 /prd-start [问题-id] 开始实施；选 2 则只提交推送供以后使用，提交信息形如 docs(prd-[问题-id]): 创建PRD #[问题-id] - [功能名称] [skip ci]，随后执行 git pull --rebase origin main && git push origin main。

输出说明：一次完整调用得到四个可见结果——带 PRD 标签的 GitHub 问题、prds/ 下的 PRD 文件、可能更新的 docs/ROADMAP.md、以及一条带 [skip ci] 的提交记录。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
dot-ai-prd-create（本技能） 文档优先的 PRD 创建工作流 自动建 GitHub 问题 + 生成按问题 ID 命名的 PRD 文件 + 里程碑规划 + 路线图联动 + 提交推送 需安装技能、安装并登录 GitHub CLI、仓库有写权限 以 GitHub 为协作中枢的研发团队做需求立项 优势：流程固定、可追溯、产出即资产；不足：强绑定 GitHub 与 gh，非 GitHub 团队不适用
通用 AI 对话直接写 PRD 一次性文本生成 输入想法，输出一份 PRD 草稿 门槛最低，无环境依赖 早期脑暴、格式参考 优势：上手快；不足：结果不稳定、无 Issue 关联、无命名与版本管理、里程碑容易写成任务清单
Notion / 飞书等文档模板 人工填写的 PRD 模板库 提供结构化 PRD 模板与数据库视图 需账号与模板搭建 产品团队日常文档协作 优势：排版与协作体验好；不足：需人工逐字撰写，与代码仓库、Issue 体系割裂
Jira / Linear 等需求管理工具 专业项目管理平台 需求条目、优先级、迭代与看板 需部署或订阅、团队迁移成本 中大型团队全流程管理 优势：报表与流程完善；不足：PRD 正文常需另建文档，与仓库文件不同源

5. 该技能的典型应用场景与实际体验情况

场景一：独立开发者 / 小团队的需求立项 角色：全栈开发者兼「产品经理」。痛点：想法很多但从不落文档，做完就忘、迭代时靠回忆。使用方式：把想法口述给技能，拿到 GitHub 问题与 PRD 文件，把 5-10 个里程碑当作待办。体验：流程感强，第一次会被追问「用户旅程是怎样的」而略感啰嗦，但正是这几问把需求问清楚了。

场景二：开源项目的功能提案规范化 角色：开源维护者。痛点：Issue 区充斥着「希望加个功能」的一句话提案，无法评估。使用方式：用技能把提案转成带「PRD」标签的问题 + 详细 PRD 链接。体验：标签让需求可筛选，PRD 里的成功标准与验证策略让「要不要接这个 PR」有了判断依据。

场景三：多需求并行期的排期管理 角色：技术负责人。痛点：同时规划多个功能，优先级全凭记忆。使用方式：批量创建多个 PRD，全部走「选项 2 提交并推送供以后使用」，并让技能写入 docs/ROADMAP.md 的短/中/长期段落。体验：路线图自动成型，[skip ci] 标志避免了纯文档提交触发流水线。

场景四：需求交付前的自检 角色：研发工程师。痛点：功能「做完了」但说不清是否达到预期。使用方式：对照 PRD 中的里程碑逐条勾选，测试与文档里程碑需在项目存在测试与用户文档时才被纳入。体验：验收标准前移，减少了上线前的返工。

整体体验：上手难度中等偏低（会描述需求即可），真正的门槛在环境侧——GitHub CLI 未安装或未登录时会中断，需要按提示补齐；注意事项是仓库权限要足够，以及不要绕过「先建问题再建文件」的顺序，否则文件名会失去依据。

6. 该技能能为用户带来的价值

  • 把「写文档」变成「跑流程」：从想清楚到落仓库只走一条路径，减少「要不要写 PRD」的决策消耗。
  • 降低规范门槛：10 个规划问题 + 里程碑正反例，让没受过产品训练的开发者也写出结构完整的 PRD。
  • 可追溯性收益：问题编号贯穿 PRD 文件名、问题链接与提交信息，需求与代码变更天然对齐，回溯成本显著下降。
  • 减少无效工作：5-10 个里程碑的上限抑制了「把任务拆成 50 条微任务」的冲动；[skip ci] 与 [skip ci] 提交约定避免纯文档改动浪费 CI 资源。
  • 长期价值：prds/ 目录 + 「PRD」标签 + ROADMAP.md 三者叠加，会在仓库里沉淀出一份随时间增长的需求档案，新人接手时可从问题与文档反推设计意图。

7. 常见问题 FAQ

Q1：这个技能怎么安装？ 在所用平台的技能市场按英文名 dot-ai-prd-create 或技能 ID 11174 安装，同时确保 GitHub CLI 已安装并登录、目标仓库有 Issue 与推送权限。具体安装入口与命令以官方说明为准。

Q2：一定要用 GitHub 吗？ 按技能详情，它的流程完全围绕 GitHub 问题、gh 命令与 prds/ 目录设计，因此更适合以 GitHub 为协作中枢的团队。若你的团队使用其他代码托管平台，需要自行改造流程。

Q3：收费吗？ 技能详情未涉及定价信息，收费标准请以官方说明为准。

Q4：为什么不直接让 AI 写一份 PRD？ 直接生成只能得到一段文本，缺少「问题 ID 驱动文件命名」「问题与文档互链」「路线图联动」「提交约定」这些流程约束。本技能的价值在于把 PRD 变成可追踪的仓库资产，而不只是一篇文章。

Q5：适合谁用？ 需要把产品想法落成可执行计划的独立开发者、开源维护者、小型研发团队，以及希望用文档管理交付节奏的技术负责人；不写 PRD、不做长期规划的一次性脚本场景则收益有限。