从想法到交付中间最容易断的一环就是 PRD它要么脱离现有代码要么写完后没有进入团队协作系统。write-a-prd 把访谈、仓库探索、架构取舍与 GitHub/Jira 工单串成一条流程目标不是写得好看而是让需求能够被接着做下…PRD 不该是“AI 写完的一篇文档”这个 Skill 先研究代码库再把需求落到工单从想法到交付中间最容易断的一环就是 PRD它要么脱离现有代码要么写完后没有进入团队协作系统。write-a-prd把访谈、仓库探索、架构取舍与 GitHub/Jira 工单串成一条流程目标不是写得好看而是让需求能够被接着做下去。它适合接在 需求梳理 之后。下面保留原始 Skill 及完整拆解。Skill 详解:write-a-prd(撰写产品需求文档 PRD)来源仓库:mattpocock/skills(write-a-prd/SKILL.md)——前端/TypeScript 教育者 Matt Pocock 维护的一套面向真实工程团队的 Claude Code / Codex skill 合集文件构成:仅一个SKILL.md文件。tags:[workflow, planning, project-management]一、Frontmatter 元信息(原文)--- name: write-a-prd description: Create a PRD through user interview, codebase exploration, and module design, then submit as an issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature. Supports both GitHub Issues and Jira. tags: [workflow, planning, project-management] ---触发条件很明确:用户想写 PRD、创建产品需求文档、或者规划一个新功能。它的最终产物不是一份 Markdown 文件放在本地,而是直接提交为 issue tracker 里的一条 issue(GitHub Issues 或 Jira 二选一)。二、SKILL.md 全文原文(中文翻译)以下为源文件SKILL.md的完整中文翻译,原文为英文,可在 mattpocock/skills 仓库 的write-a-prd/SKILL.md查看。这个技能会在用户想要创建 PRD 时被调用。如果你认为某些步骤没有必要,可以跳过。 1. 请用户用一段长而详细的文字描述他们想解决的问题,以及任何可能的解决思路。 2. 探索代码仓库,核实用户所述内容是否属实,了解当前代码库的现状。 3. 就这份方案的方方面面对用户进行不厌其烦的访谈,直到达成共识为止。沿着设计决策树的每一个分支,逐一解决决策之间的依赖关系。 4. 勾勒出完成本次实现所需要新建或修改的主要模块。主动寻找机会,把功能抽取成可以独立测试的深模块(deep module)。 所谓深模块(相对于浅模块而言),是指用一个简单、稳定、几乎不会变化的可测试接口,封装了大量功能的模块。 和用户核实这些模块是否符合他们的预期。和用户确认希望为哪些模块编写测试。 5. 当你对问题和解决方案有了完整的理解之后,使用下面的模板撰写 PRD。这份 PRD 应当作为一条 issue 提交到项目所配置的工单系统中。 **工单系统探测方式:** - 检查 CLAUDE.md 中是否配置了工单系统(例如是否存在 ### Ticket Grooming 小节,或者写明了 Jira 项目 key) - 如果配置的是 Jira:通过 Atlassian MCP 的 createJiraIssue 创建,issue 类型设为 Story,并打上 claude-code 标签 - 如果用的是 GitHub Issues:通过 gh issue create 命令行创建 - 如果两者都没配置:直接询问用户要提交到哪里 - 提交到 Jira 时,描述内容的 contentFormat 必须始终设置为 markdown prd-template ## 问题陈述(Problem Statement) 站在用户的视角,描述用户正面临的问题。 ## 解决方案(Solution) 站在用户的视角,描述该问题的解决方案。 ## 用户故事(User Stories) 一份很长的、带编号的用户故事列表。每条用户故事应采用如下格式: 1. 作为一名 角色,我希望获得 功能,以便 收益 user-story-example 1. 作为一名手机银行用户,我希望能看到账户余额,以便更明智地安排我的支出决策 /user-story-example 这份用户故事列表应当极其详尽,覆盖该功能的所有方面。 ## 实现决策(Implementation Decisions) 已经做出的一系列实现决策的列表。可以包括: - 将要新建/修改的模块 - 这些模块中将被修改的接口 - 来自开发者的技术澄清说明 - 架构决策 - Schema 变更 - API 契约 - 具体的交互方式 **不要**在其中写具体的文件路径或代码片段——它们很可能很快就会过时。 ## 测试决策(Testing Decisions) 已经做出的一系列测试决策的列表。应包含: - 什么样的测试才算是好测试的说明(只测试外部行为,不测试实现细节) - 哪些模块将会被测试 - 相关测试的既有范例(即代码库里已经存在的同类测试写法) ## 不在本次范围内(Out of Scope) 描述本 PRD 不涉及的内容。 ## 补充说明(Further Notes) 关于该功能的任何其他补充说明。 /prd-template三、实现原理与工作机制同样是纯 prompt 化的 skill,没有脚本或数据文件,核心价值在于流程 模板 落地渠道对接三件事的组合:五步走流程:- Step 1:先让用户倒垃圾——用长文本详细描述问题和可能的解决思路,不加约束地先收集原始输入。- Step 2:Claude 主动去探索代码仓库,验证用户说法是否属实、了解当前代码库现状——这一步把需求和现实的代码约束对齐,避免 PRD 写出脱离实际的东西。- Step 3:Interview the user relentlessly(不厌其烦地盘问用户),按设计决策树的每个分支逐一解决依赖关系。这是刻意强调的高强度访谈,直到达成shared understanding(双方共识)为止。- Step 4:勾勒出需要新建/修改的主要模块,并主动寻找可以抽取成深模块(deep module)的机会。文件里对深模块给出了明确定义:用简单、稳定、可单独测试的接口封装大量功能的模块(区别于浅模块——接口复杂但内部功能少)。这明显借鉴自 John Ousterhout《A Philosophy of Software Design》里的核心概念。之后还要跟用户逐一确认这些模块是否符合预期、哪些模块需要写测试。- Step 5:所有信息齐全后,套用下面的prd-template模板撰写正式 PRD,并提交为 issue tracker 里的一条 issue。Issue tracker 自动探测逻辑:- 先检查项目的CLAUDE.md里是否配置了工单系统(比如是否存在### Ticket Grooming段落,或者写明了 Jira 项目 key)。- 如果配置的是 Jira:通过 Atlassian MCP 的createJiraIssue创建,issue 类型固定为 Story,打上claude-code标签,并且提交内容的contentFormat必须设为markdown。- 如果用的是 GitHub Issues:走gh issue create命令行创建。- 如果两者都没配置:直接问用户提交到哪里,而不是自作主张。PRD 模板结构(prd-template)固定为六个部分:Problem Statement(问题陈述,站在用户视角)→ Solution(解决方案,同样站在用户视角)→ User Stories(要求extremely extensive,用标准的 As aactor, I want afeature, so thatbenefit 格式,并给出了银行 App 余额展示的例子)→ Implementation Decisions(实现决策:涉及模块、接口、架构、schema、API 等,但明确禁止写具体文件路径或代码片段,理由是会很快过时)→ Testing Decisions(测试决策:强调只测外部行为,不测实现细节,并要参考代码库里已有的同类测试写法)→ Out of Scope / Further Notes。四、使用场景用户说帮我写个 PRD写一份产品需求文档帮我规划一个新功能并建个 ticket。团队使用 GitHub Issues 或 Jira 作为需求管理系统,希望 AI 产出的 PRD 能直接落地成一条可追踪的 issue,而不是丢一份 Markdown 文件在本地了事。适合中大型功能的规划阶段,尤其是需要先摸清代码库现状、再和相关方反复确认的场景。和上面brainstormingskill 相比,这个更偏正式交付物和团队协作沉淀,而不是单纯的个人构思阶段。五、亮点总结深模块设计理念的显式引入,把架构设计的行业最佳实践直接写进了 skill 流程里,引导 Claude 在做模块拆分时不只是照抄现有结构,而是主动寻找封装点。对接真实工单系统(GitHub/Jira)的探测优先级和调用方式写得非常具体,包括 Jira 的 issue type、标签、contentFormat参数,这些都是容易在实践中被忽略的细节,写清楚后能避免生成的 PRD 有内容没有 owner / 没有留痕。User Stories 部分要求LONGextremely extensive,这是刻意的过度覆盖策略,倾向于让 PRD 覆盖尽量多的边界场景,而不是只写主干流程。Implementation Decisions 里禁止写具体文件路径或代码片段体现了对 PRD 文档保鲜度(与代码库不同步腐化)的重视,这是很多团队写 PRD 时容易踩的坑。