to-prd

此技能会利用当前对话上下文和对代码库的理解来编写 PRD。不要采访用户——只需综合已有信息。

问题跟踪器和分类标签词汇应已提供给你；如果没有，请运行 /memo-flow。

流程

1. 如果你还不了解代码库的当前状态，请先探索代码仓库。通篇使用项目的领域术语表中的词汇，并遵循你正在处理领域内的 ADR。

2. 概述完成实现所需构建或修改的主要模块。积极寻找提取深层模块的机会，以便单独测试。

深层模块（与浅层模块相对）是指封装大量功能，同时提供简单、可测试且很少变化的接口的模块。

请用户确认这些模块是否符合预期，并询问他们希望为哪些模块编写测试。

3. 使用下方模板编写 PRD，然后将其发布到项目问题跟踪器。应用 ready-for-agent 分类标签——无需额外分类。

问题陈述

从用户的角度描述他们遇到的问题。

解决方案

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

用户故事

一份篇幅较长、带编号的用户故事列表。每条用户故事的格式应为：

1. 作为一名 <角色>，我希望拥有 <功能>，以便 <收益>

1. 作为一名手机银行客户，我希望查看账户余额，以便更好地了解自己的消费情况

这份用户故事列表应尽可能详尽，涵盖该功能的所有方面。

实现决策

列出已作出的实现决策，包括：

• 将要构建或修改的模块
• 将要修改的模块接口
• 开发人员提供的技术说明
• 架构决策
• 架构变更
• API 契约
• 具体交互

不要包含具体文件路径或代码片段。这些内容很快就可能过时。

例外：如果原型生成的代码片段比文字更准确地表达了某项决策（如状态机、归约器、架构），则可将其内联放在相关决策中，并简要注明该内容来自原型。仅保留能体现决策的部分——不要提供可运行的演示，只保留重要内容。

测试决策

列出已作出的测试决策，包括：

• 优秀测试的标准（只测试外部行为，不测试实现细节）
• 将要测试的模块
• 测试的先例（即代码库中的类似测试）

不在范围内

描述不在本 PRD 范围内的事项。

补充说明

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