write-a-prd

name	write-a-prd
description	通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。

当用户希望创建 PRD 时，将调用本技能。你可以根据需要跳过其中一些步骤。

1. 向用户索要对他们想解决的“问题”的长篇、细节充分的描述，以及任何潜在的解决思路。

2. 探索仓库以验证他们的判断，并理解当前代码库的现状。

3. 不断地“访谈用户”：围绕方案树的每个分支追问，直到你们对设计形成共同理解。要逐步走过设计树的每条路径，逐个解决决策之间的依赖关系。

4. 在你理解这些决策之后，勾勒出你需要构建或修改的主要模块。并积极寻找可将“深模块（deep modules）”抽取出来、以便能在隔离环境下进行测试的机会。

所谓深模块（deep module），与浅模块（shallow module）相对：它会把大量功能封装进一个简单、可测试的接口，并且很少会频繁变化。

和用户一起确认这些模块是否符合他们的预期，并让用户确认：哪些模块希望你为其编写测试。

5. 当你已经对问题与解决方案形成完整理解后，使用下面的模板来撰写 PRD。PRD 应以 GitHub issue 的形式提交。

问题陈述（Problem Statement）

从用户视角来看，用户正面临的那项问题。

解决方案（Solution）

从用户视角来看，针对该问题的解决方案。

用户故事（User Stories）

一份非常长的、带编号的用户故事清单。每条用户故事应采用以下格式：

1. 作为一个 ，我希望能够 ，以便

1. 作为移动银行客户，我希望能查看我账户的余额，以便我能更好地做出关于支出的决策

这份用户故事清单应当尽可能详尽，并覆盖功能的各个方面。

实现决策（Implementation Decisions）

实现决策列表。可能包括：

• 将要构建/修改的模块
• 将要修改的这些模块的接口
• 来自开发者的技术澄清
• 架构层面的决策
• schema 的变更
• API 合约（API contracts）
• 具体交互方式

不要包含具体文件路径或代码片段。这些内容很可能会在后续很快变得过时。

测试决策（Testing Decisions）

测试决策列表。需要包含：

• 你认为“一条好测试”应当是什么（只测试外部行为，不测试实现细节）
• 需要被测试的模块
• 测试的先例/参考（即仓库中类似类型测试的对照）

不在范围内（Out of Scope）

描述本 PRD 中明确不包含的内容。

进一步备注（Further Notes）

关于该功能的其他补充说明。