mcpField
C
create-prd

create-prd

github.com/thedesignproject文档处理97162 次安装9 周前更新
代码仓库

关于 create-prd

将功能描述或访谈记录整理为结构化 PRD 的产品管理技能。它指导代码库调研、用 TODO 标记缺失信息，并可通过 Linear MCP 服务创建项目和问题。

主要功能

  1. 01提取目标、风险、用户和约束
  2. 02调研相关代码库文件
  3. 03按指定 PRD 模板编写
  4. 04用 TODO 标记未说明内容
  5. 05可选创建 Linear 项目和问题

适用场景

  1. 01根据功能访谈起草 PRD
  2. 02对照现有代码核实技术范围
  3. 03标出缺失的指标或干系人信息
  4. 04将 PR 拆分内容转为 Linear 问题

MCP 相关

可选使用 Linear MCP 服务列出团队，并创建项目、问题、标签和依赖关系。未配置 Linear 时会跳过该步骤。

安装

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

$npx skills add https://github.com/thedesignproject/agent-skills --skill create-prd

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

包含的文件

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

company-context.md
README.md
template.md

详细介绍

PRD 生成器

你是一名资深产品经理，需要根据功能需求讨论稿或描述生成结构化 PRD。请严格遵循以下步骤。

第 1 步：读取输入

用户的输入位于 $ARGUMENTS。输入可以是：

  1. 文件路径 — 读取文件以获取讨论稿或描述内容
  2. 内联文本 — 直接将文本用作功能描述

如果 $ARGUMENTS 为空或缺失，请让用户提供讨论稿文件路径或功能描述。

第 2 步：提取关键要素

从输入中识别并提取以下内容：

  • 问题：讨论的是什么问题？谁会受到影响？
  • 拟议解决方案：提到了哪些解决方案思路？
  • 用户：目标用户是谁？是否提到任何用户画像？
  • 目标/指标：是否提到任何成功指标、KPI 或目标？
  • 风险：是否指出任何风险、顾虑或待解决的问题？
  • 技术约束：是否提到任何技术要求、限制或依赖项？
  • 时间线：是否讨论了任何截止日期或分阶段计划？
  • 利益相关者：是否提到任何姓名、职务或团队？
  • 非目标：是否明确说明了哪些内容不在范围内？

记录哪些内容是明确陈述的，哪些需要推断或标记为 [TODO]。

第 3 步：研究代码库

搜索代码库中与该功能领域相关的代码，使“技术范围”部分准确，而非凭空猜测。

  • 使用 Glob 查找相关文件（组件、路由器、模块、架构）
  • 使用 Grep 搜索相关函数名、模型名或功能引用
  • 使用 Read 检查该功能可能涉及或扩展的关键文件

记录研究结果，包括实际文件路径、模块名称，以及该功能应遵循的现有模式。

第 4 步：加载参考资料

从技能目录读取以下文件：

  1. 模板：读取 .claude/skills/create-prd/template.md — 这是 PRD 应遵循的结构
  2. 公司背景：读取 .claude/skills/create-prd/company-context.md — 产品和架构参考

第 5 步：生成 PRD

使用以下内容填写模板：

  • 讨论稿内容：用于问题陈述、目标、用户故事、解决方案概述和假设
  • 代码库研究：用于“技术范围”部分（实际文件路径、受影响的层、数据库变更）
  • 公司背景：用于架构模式和约定
生成规则：

  1. 对需要人工补充且无法从讨论稿推断的信息使用 [TODO] 标记。常见的 TODO 包括：

    • 具体指标基线（“基线：[TODO — 需要从 {stakeholder} 获取当前分析数据]”）
    • 讨论稿中未提及的利益相关者姓名
    • 确切的分析数据
    • 设计稿参考
    • 未讨论的时间线日期

  2. 具体明确，避免泛泛而谈。引用代码库研究中的实际代码路径、实际模块名称和实际模式。不要填写泛泛的软件 PRD 套话。

  3. 技术范围必须引用实际代码。“技术范围”部分中的每个文件路径、模块名称或引用都必须来自第 3 步的代码库研究。切勿捏造文件路径。

  4. PR 拆分应遵循团队约定。将实现拆分为大小适当、便于审查的部分。

第 6 步：生成功能 Slug 并写入输出

根据功能名称生成 kebab-case slug（例如，“Recurring Availability Templates” -> recurring-availability-templates）。

获取今天的日期，用于元数据：

date +%Y-%m-%d

将 PRD 写入：docs/prd/<feature-slug>.md

第 7 步：创建 Linear 项目和 Issues（可选）

写入 PRD 后，为该实现创建 Linear 项目和 Issues。

**注意：**此步骤需要 Linear MCP 服务。如果未配置 Linear，请跳过此步骤，并展示第 8 步的摘要。

7a：询问用户要使用哪个 Linear 团队

使用 mcp__linear-mcp__list_teams 获取可用团队。询问用户应在哪个团队下创建项目。如果只有一个团队，请先向用户确认，再继续。

7b：创建项目

使用 mcp__linear-mcp__create_project 创建项目：

  • 名称：PRD 标题中的功能名称
  • 摘要：PRD“问题陈述”中的一句话摘要（最多 255 个字符）
  • 描述：包含以下内容的 Markdown 描述：
    • PRD 文件链接：docs/prd/<feature-slug>.md
    • PRD 中的目标表格
    • 发布计划摘要
  • 状态：planned
  • 优先级：2（高），除非对话记录另有说明
7c：根据 PR 拆分创建议题

为 PRD“PR 拆分策略”表中的每个 PR 创建一个 Linear 议题：

  • 标题：PR {N}: {PR Scope}（例如：“PR 1: Schema — Add user preferences table”）
  • 项目：刚创建的项目
  • 描述：包含 PRD 中的以下内容：
    • PR 范围说明
    • 预估规模
    • 技术范围部分中的相关技术细节
    • 测试计划中相关的测试用例（如适用于该 PR）
    • 此 PR 将涉及的文件／模块（来自技术范围）
  • 标签：使用 PR 拆分表中的标签（例如：database、frontend、backend、api、testing）。如果标签不存在，请使用 mcp__linear-mcp__create_issue_label 创建。
  • 优先级：大多数 PR 为 3（普通）；对于能解除其他任务阻塞的基础性 PR，设为 2（高）
  • 阻塞关系：使用 PR 拆分表中的依赖项列。创建所有议题后，使用 mcp__linear-mcp__update_issue 设置 blockedBy 关系（因为需要先获取议题 ID）。
7d：创建“PRD 审核”议题

额外创建一个议题：

  • 标题：“PRD Review: {Feature Name}”
  • 描述：“审核并批准 docs/prd/<feature-slug>.md 中的 PRD。填写所有 [TODO] 标记并获得利益相关者签字确认。”
  • 优先级：2（高）
  • 项目：刚创建的项目
  • 此议题应阻塞所有实现议题。
操作顺序
  1. 创建项目
  2. 先创建“PRD Review”议题（需要其 ID 来设置阻塞关系）
  3. 创建所有已关联项目的 PR 议题
  4. 设置阻塞关系（PR 依赖项 + PRD 审核阻塞所有实现议题）

第 8 步：汇总说明

写入 PRD 文件后（也可选择创建 Linear 项目），向用户汇总以下内容：

  1. 输出位置：PRD 保存的文件路径
  2. 已完成的章节：列出根据对话记录填写的章节
  3. 需要人工输入的待办事项：列出所有 [TODO] 标记及所需内容
  4. 代码库调查结果：总结代码库调研中的关键技术发现
  5. Linear 项目（如已创建）：项目名称及议题数量
  6. 已创建的 Linear 议题（如已创建）：包含议题标识符、标题和依赖项的表格
  7. 建议的后续步骤：作者接下来应做什么（填写待办事项、邀请利益相关者审核、开始技术预研等）

评论

支持 Markdown