to-prd

此技能获取当前对话上下文和代码库理解并生成 PRD。不要采访用户——只是综合你已经知道的内容。

问题跟踪器和分类标签词汇应该已经提供给你——如果没有，运行 /setup-matt-pocock-skills。

流程

1. 如果尚未这样做，探索仓库以了解代码库的当前状态。在整个 PRD 中使用项目的领域词汇表词汇，并尊重你正在接触的区域中的任何 ADR。

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

深层模块（与浅层模块相对）是一个在简单、可测试且很少变化的接口中封装大量功能的模块。

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

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

问题陈述

用户面临的问题，从用户的角度。

解决方案

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

用户故事

一个长的编号用户故事列表。每个用户故事应采用以下格式：

1. 作为 <角色>，我想要 <特性>，以便 <收益>

1. 作为移动银行客户，我想要查看我的账户余额，以便我对支出做出更明智的决策

这个用户故事列表应该非常广泛，涵盖特性的所有方面。

实现决策

做出的实现决策列表。这可以包括：

• 将要构建/修改的模块
• 将要修改的那些模块的接口
• 开发者的技术澄清
• 架构决策
• 模式变更
• API 合同
• 特定交互

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

例外：如果原型产生的片段比散文更精确地编码决策（状态机、reducer、模式、类型形状），将其内联在相关决策中并简要说明它来自原型。修剪到决策丰富的部分——不是工作演示，只是重要的部分。

测试决策

做出的测试决策列表。包括：

• 什么构成好的测试的描述（仅测试外部行为，而不是实现细节）
• 哪些模块将被测试
• 测试的先例（即代码库中类似类型的测试）

超出范围

对此 PRD 超出范围的事物的描述。

进一步说明

关于特性的任何进一步说明。