to-prd

name	to-prd
description	将当前对话上下文转化为 PRD 并作为 GitHub issue 提交. 当用户想要从当前上下文创建 PRD, 提到 "生成 PRD" 或 "写需求文档" 时使用.

此技能将当前对话上下文和代码库理解转化为 PRD. 不要访谈用户 -- 只需综合你已经知道的内容.

流程

1. 探索仓库以了解代码库的当前状态(如果尚未完成).

2. 勾画出完成实现所需构建或修改的主要模块. 积极寻找可以独立测试的深度模块提取机会.

深度模块(相对于浅层模块)是指在简单, 可测试的接口中封装大量功能的模块, 该接口很少改变.

与用户确认这些模块符合他们的期望. 与用户确认他们希望为哪些模块编写测试.

3. 使用下面的模板编写 PRD 并将其作为 GitHub issue 提交.

问题陈述

从用户角度描述用户面临的问题.

解决方案

从用户角度描述问题的解决方案.

用户故事

一个详细的, 带编号的用户故事列表. 每个用户故事应采用以下格式:

1. 作为一个 <角色>, 我想要 <功能>, 以便 <收益>

1. 作为移动银行客户, 我想要查看账户余额, 以便我可以更明智地决定我的支出

此用户故事列表应该极其详尽, 涵盖功能的所有方面.

实现决策

已做出的实现决策列表. 这可以包括:

• 将要构建/修改的模块
• 将要修改的这些模块的接口
• 来自开发人员的技术澄清
• 架构决策
• Schema 更改
• API 契约
• 特定交互

不要包含特定文件路径或代码片段. 它们可能很快就会过时.

测试决策

已做出的测试决策列表. 包括:

• 对什么是好测试的描述(仅测试外部行为, 而非实现细节)
• 将要测试的模块
• 测试的先例(即代码库中类似类型的测试)

范围外

对此 PRD 范围外事项的描述.

进一步说明

关于该功能的任何进一步说明.