mcpField
C
create-prd

create-prd

github.com/borghei开发1.0k143 次安装6 天前更新
代码仓库

关于 create-prd

create-prd 是用于编写产品需求文档的技能，面向产品团队及跨职能利益相关者。它以八部分框架、问题梳理和脚手架生成器帮助明确需求与成功指标。

主要功能

  1. 01八部分 PRD 框架
  2. 02问题与需求前期梳理
  3. 03SMART 关键结果与 JTBD
  4. 04脚手架生成器
  5. 05原型优先编写指引

适用场景

  1. 01为新产品启动编写需求文档
  2. 02为重大功能扩展协调团队
  3. 03在开发前明确范围与成功指标

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/borghei/claude-skills --skill create-prd

安装后在 Claude Code 中输入/create-prd确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
prd_template.md
examples/
shared-dashboards-prd.md
references/
prd-framework.md
prd-writing-guide.md
red-flags.md
scripts/
prd_scaffolder.py

详细介绍

PRD 搭建专家

概述

使用经过验证的 8 部分框架，结构化地创建产品需求文档。此技能可生成清晰、没有行话的 PRD，说明要构建什么、为何重要，以及如何衡量成功。生成的每份 PRD 都遵循统一结构，确保工程、设计和业务相关方保持一致。

核心能力

  • PRD 前期梳理 — 通过问题梳理画布（从用户视角展开叙述）和逆向工作新闻稿，在提出解决方案前厘清问题。
  • 8 部分 PRD 框架 — 概述、联系人、背景、目标（SMART KR）、市场细分（JTBD）、价值主张（价值曲线）、解决方案（P0/P1/P2）、发布。
  • 通俗语言规范 — 每句话只表达一个想法，具体表达优先于抽象表达，通过 10 秒高管测试。
  • 脚手架自动化 — prd_scaffolder.py 会生成带有引导性占位内容的框架。

适用场景

  • 新产品计划 -- 从零开始开发产品，并且需要在开发开始前准备一份完整的规格说明。
  • 功能扩展 -- 为现有产品添加重要功能，需要跨团队保持一致。
  • 相关方对齐 -- 需要一份能为所有相关人员解答“我们要构建什么，为什么要构建？”的文档。

先澄清

生成 PRD 前，请确认以下信息。如果有任何信息未知或含糊不清，请提问，不要自行假设：

  • 核心问题 — 用用户自己的话写成一句话；说明谁受到影响以及如何受影响（决定背景和目标）
  • 目标读者 — 高管、工程团队或混合受众（决定内容深度，以及 8 个部分中哪些最重要）
  • 成功指标 — 用于定义“成功”的 SMART KR（决定目标）
  • 范围边界 — 明确本次发布不包含哪些内容（决定解决方案的 P0/P1/P2 和发布）

停止规则：只询问最可能改变输出的 2–3 个问题。如果用户说“直接起草”，就继续撰写，并在 PRD 开头列出假设。

快速开始

python scripts/prd_scaffolder.py --product-name "MyProduct" \
  --objective "Short description of the outcome" \
  --segments "Segment A, Segment B"
  1. 收集背景信息：产品名称、目标细分群体、核心问题。
  2. （可选）先使用问题梳理画布或逆向工作新闻稿梳理问题（参见 references/prd-framework.md）。
  3. 运行脚手架生成框架，然后填写 8 个部分。
  4. 根据 references/prd-writing-guide.md 中的清单进行检查，然后分享以征求反馈。

原型优先路径

对于某些工作，AI 应用构建工具、AI 设计工具和 AI 编码助手可以让制作可点击或可运行的原型，比撰写冗长的规格说明更省力。用原型来探索，用 PRD 来做决策。

在以下情况下，先构建原型（或与规格说明同步构建）：

  • 核心风险在于可用性或吸引力（“用户能理解／会想要吗？”），而非可行性或政策。
  • 难以用文字描述交互（新工作流、复杂 UI、对话流程）。
  • 利益相关者正围绕不同意见争论，而 20 分钟的用户访谈就能得出结论。

**在以下情况下，先撰写规格说明：**风险涉及监管、数据、安全、定价或跨团队依赖；或者变更只是对现有流程中已充分理解部分的扩展。

与用户测试原型：

  1. 在测试开始前写下假设和通过门槛（参见 discovery/brainstorm-experiments/）。
  2. 面向目标细分群体开展 5-8 场基于任务的测试；观察用户，不要演示。
  3. 使用真实但合成的数据——未经批准，绝不要将客户 PII 粘贴到第三方原型工具中。
  4. 将用户的实际行为（任务成功率、错误、耗时）与他们的口头反馈分开记录。

**PRD 仍必须包含：**问题及受影响的人群（背景）、成功指标（目标 KR）、约束（技术、法律、预算、时间线）、明确的非目标，以及风险／待解决问题。在第 7 节（解决方案）中链接原型和测试结果——原型用于展示解决方案，不能替代需求。

**交接给工程团队：**标明原型是临时方案还是起点，并说明是哪一种。生成的原型代码默认不能用于生产——列出其中省略的内容（身份验证、错误状态、无障碍性、性能、安全审查、数据模型），以便工程团队评估实际构建的工作范围。将原型链接、经过测试的流程、测试结果以及 P0/P1/P2 范围一并交接。

参考资料

  • references/prd-framework.md — 撰写时阅读：两种 PRD 前置技巧、包含各章节指导的完整 8 节框架、写作原则、脚手架工具标志参考、故障排查和成功标准。
  • references/prd-writing-guide.md — 润色草稿时阅读：逐节写作指南和审查清单。
  • references/red-flags.md — 分享 PRD 前阅读：PRD 常见问题及好／坏示例和修正方法。
  • assets/prd_template.md — 可直接填写的完整 PRD 模板。

范围与限制

**范围内：**生成包含引导式占位内容的 8 节 PRD 框架；逐节写作指导（通俗易懂、具体明确）；按待完成的工作定义市场细分；使用 Value Curve 绘制价值主张图；使用 Now/Next/Later 规划发布，并明确标注延期事项。

**范围外：**技术架构或系统设计文档（engineering/）；用户故事撰写和待办事项创建（execution/job-stories/、execution/wwas/）；详细的 UX 研究或可用性测试计划（product-team/）；财务商业案例建模（finance/）。

**重要注意事项：**PRD 是沟通工具，不是合同——应将其视为持续更新的文档。8 节框架经过实践验证，但轻量级敏捷团队可能只需要第 1、3、4、7、8 节，而受监管的场景可能需要更多内容。需求不清晰或缺失是有充分记录的返工原因，因此应在开始构建前与工程和设计团队一起审查 PRD。

集成点

集成方向描述
discovery/identify-assumptions/接收自经过验证且标记为“立即测试”的假设会连同证据填入 PRD 第 7 节
discovery/brainstorm-experiments/接收自实验结果用于验证或推翻 PRD 中的假设
discovery/pre-mortem/接收自Tiger 风险缓解措施会成为 PRD 的风险章节
execution/brainstorm-okrs/传递至PRD 关键结果（第 4 节）与季度 OKR 目标保持一致
execution/outcome-roadmap/传递至PRD 发布计划（第 8 节）对应路线图的 Now/Next/Later 时间范围
execution/prioritization-frameworks/接收自第 7 节中的功能优先级（P0/P1/P2）参考 RICE/ICE 评分确定
senior-pm/传递至PRD 中的利益相关者背景信息为利益相关者映射工具的参与计划提供依据

评论

支持 Markdown