---
name: to-prd
description: 将当前对话上下文转化为 PRD 并发布到项目 Issue 跟踪器。当用户想要从当前上下文创建 PRD 时使用。
---

# 转化为 PRD

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

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

## 流程

1. 探索仓库以了解代码库的当前状态（如果你还没有这样做）。在 PRD 中全程使用项目的领域词汇表，并尊重你触及区域中的任何 ADR。

2. 草拟你将需要构建或修改以完成实现的主要模块。积极寻找可以独立测试的深模块的提取机会。

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

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

3. 使用下面的模板编写 PRD，然后将其发布到项目 Issue 跟踪器。应用 `needs-triage` 分类标签，使其进入正常分类流程。

<PRD 模板>

## 问题陈述

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

## 解决方案

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

## 用户故事

一份详细的、编号的用户故事列表。每个用户故事应按以下格式编写：

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

<用户故事示例>
1. 作为移动银行客户，我想要查看我的账户余额，以便我能做出更明智的支出决策
</用户故事示例>

此用户故事列表应尽可能详尽，覆盖功能的所有方面。

## 实现决策

一份已做出的实现决策列表。可包括：

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

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

## 测试决策

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

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

## 范围外

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

## 进一步说明

关于此功能的任何进一步说明。

</PRD 模板>
