write-a-prd

name write-a-prd description 通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。 当用户希望创建 PRD 时，将调用本技能。你可以根据需要跳过其中一些步骤。 向用户索要对他们想解决的“问题”的长篇、细节充分的描述，以及任何潜在的解决思路。 探索仓库以验证他们的判断，并理解当前代码库的现状。 不断地“访谈用户”：围绕方案树的每个分支追问，直到你们对设计形成共同理解。要逐步走过设计树的每条路径，逐个解决决策之间的依赖关系。 在你理解这些决策之后，勾勒出你需要构建或修改的主要模块。并积极寻找可将“深模块（deep modules）”抽取出来、以便能在隔离环境下进行测试的机会。 所谓深模块（deep module），与浅模块（shallow module）相对：它会把大量功能封装进一个简单、可测试的接口，并且很少会频繁变化。 和用户一起确认这些模块是否符合他们的预期，并让用户确认：哪些模块希望你为其编写测试。 当你已经对问题与解决方案形成完整理解后，使用下面的模板来撰写 PRD。PRD 应以 GitHub issue 的形式提交。 问题陈述（Problem Statement） 从用户视角来看，用户正面临的那项问题。 解决方案（Solution） 从用户视角来看，针对该问题的解决方案。 用户故事（User Stories） 一份非常长的、带编号的用户故事清单。每条用户故事应采用以下格式： 作为一个 ，我希望能够 ，以便 1. 作为移动银行客户，我希望能查看我账户的余额，以便我能更好地做出关于支出的决策 这份用户故事清单应当尽可能详尽，并覆盖功能的各个方面。 实现决策（Implementation Decisions） 实现决策列表。可能包括： 将要构建/修改的模块 将要修改的这些模块的接口 来自开发者的技术澄清 架构层面的决策 schema 的变更 API 合约（API contracts） 具体交互方式 不要 包含具体文件路径或代码片段。这些内容很可能会在后续很快变得过时。 测试决策（Testing Decisions） 测试决策列表。需要包含： 你认为“一条好测试”应当是什么（只测试外部行为，不测试实现细节） 需要被测试的模块 测试的先例/参考（即仓库中类似类型测试的对照） 不在范围内（Out of Scope） 描述本 PRD 中明确不包含的内容。 进一步备注（Further Notes） 关于该功能的其他补充说明。