to-prd

name	to-prd
description	将当前对话上下文和代码库理解转化为 PRD（产品需求文档）并发布到项目 backlog。适用于需求讨论完成后，需要将共识落地为文档的场景。

此技能基于当前对话上下文和对代码库的理解来生成 PRD。不要追问用户——仅基于已有信息进行综合整理。

如果尚未配置好 backlog 后端和 triage 标签体系，请先运行 /setup-matt-pocock-skills。

流程

1. 探索仓库，了解代码库当前状态（如果尚未做）。在整个 PRD 中使用项目的领域术语，并遵守相关区域的 ADR（架构决策记录）。

2. 勾勒主要模块，识别需要新建或修改哪些模块来完成实现。积极寻找可以提取为"深度模块"（deep module）的机会——这类模块封装大量功能，提供简单、可测试且不易变动的接口。

   与用户确认这些模块是否符合预期，以及用户希望对哪些模块编写测试。

3. 按以下模板撰写 PRD，然后发布到项目 backlog。打上 needs-triage 标签以便进入正常的三级流程。

问题陈述

从用户视角描述所面临的问题。

解决方案

从用户视角描述解决方案。

用户故事

一份长长的、编号的用户故事列表。每个用户故事的格式为：

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

1. 作为手机银行客户，我想要查看账户余额，以便做出更明智的消费决策

用户故事列表应尽可能详尽，覆盖该功能的各个方面。

实现决策

已做出的实现决策清单，可包括：

• 将要构建/修改的模块
• 这些模块将要修改的接口
• 来自开发者的技术澄清
• 架构决策
• 数据库 Schema 变更
• API 契约
• 具体的交互方式

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

测试决策

已做出的测试决策清单，包括：

• 好测试的标准（只测试外部行为，不测试实现细节）
• 哪些模块需要测试
• 测试的参考依据（即代码库中类似的测试范例）

非范围

明确说明本次 PRD 不涉及的内容。

补充说明

关于该功能的任何补充说明。