write-a-prd

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

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

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

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

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

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

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

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

问题陈述（Problem Statement）

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

解决方案（Solution）

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

用户故事（User Stories）

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

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

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

实现决策（Implementation Decisions）

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

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

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

测试决策（Testing Decisions）

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

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

不在范围内（Out of Scope）

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

进一步备注（Further Notes）

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