---
name: context-to-prd
description: 根据当前对话上下文和代码库理解生成 PRD，保存到 docs/prd/{feature-name}/prd.md。不采访用户，直接综合已知信息。
---

本 skill 基于当前对话上下文和代码库现状生成 PRD。不主动采访用户——直接综合你已掌握的信息。

## 流程

### 1. 探索代码库

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

### 2. 梳理模块

梳理需要新建或修改的主要模块。主动寻找可以独立测试的深度模块机会。

**深度模块**（相对于浅层模块）：封装大量功能，对外暴露简单且稳定的接口，便于独立测试。

与用户确认这些模块是否符合预期，并确认哪些模块需要编写测试。

### 3. 编写并保存 PRD

按照下方模板编写 PRD，保存到 `docs/prd/{feature-name}/prd.md`（目录不存在时自动创建）。

`{feature-name}` 使用小写短横线命名，例如 `user-auth`、`payment-flow`。

<prd-template>

## 问题陈述

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

## 解决方案

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

## 用户故事

详细的编号用户故事列表，覆盖功能的所有方面。每条格式：

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

<示例>
1. 作为移动端银行用户，我希望能查看账户余额，以便做出更合理的消费决策
</示例>

列表应尽量详尽，覆盖所有使用场景。

## 实现决策

已确定的实现决策列表，可包括：

- 需要新建或修改的模块
- 相关模块接口的变更
- 开发者的技术澄清
- 架构决策
- 数据库 Schema 变更
- API 契约
- 关键交互逻辑

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

例外：如果原型产出的代码片段能比文字更精确地表达某个决策（状态机、reducer、schema、类型定义），可以内联到对应决策中，并注明来自原型。只保留决策关键部分，不要完整的可运行示例。

## 测试决策

已确定的测试决策列表，包括：

- 好测试的标准（只测试外部行为，不测试实现细节）
- 需要编写测试的模块
- 测试参考（代码库中类似的测试示例）

## 范围外

本 PRD 明确不包含的内容。

## 补充说明

关于本功能的其他备注。

</prd-template>