# To Prd

> 将当前对话上下文转化为 PRD。适用于用户要求产出 PRD、需求文档，或说「写个 PRD」「出需求文档」「to-prd」等场景。

- Skill: `zuozh11/to-prd` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zuozh11/to-prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zuozh11/to-prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: zuozh11 (https://skillmd.com/u/zuozh11)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zuozh11/to-prd

---


# To PRD

将当前对话上下文和代码库理解合成为一份 PRD，存放在 `docs/scratch/<NN>-<中文需求名称>/PRD.md`。`NN` 记录需求进入仓库的先后顺序；中文需求名称使用 `CONTEXT.md` 中的统一术语。

PRD 按实际交付范围组织，不预设数量或类型。交付范围使用项目已有的边界名称。

## 流程

### 1. 加载项目上下文

使用已加载的 CONTEXT 术语与 RULE。尚未加载则按项目知识协议执行；知识不可用时继续并如实说明。

### 2. 追问对齐上下文

以产出高质量 PRD 为目标，启动 `ask-me`。即使当前材料看起来已经完整，也必须进入 `ask-me`，不得由本 Skill 自行宣布「需求已明确」并跳过。

启动前把下列已确认决策交给 `ask-me`，视为已锁定，不得再问：本轮用户确认、已有 PRD 的 Implementation Decisions、对应 `WAYFINDER.md` 的 Decisions so far 及已关闭决策票 Resolution。`ask-me` 只追问仍会改变实现分支、数据口径、状态变化、权限范围或接口契约、且尚未锁定的取舍。

`ask-me` 可以 0 轮返回。返回后按「写法」检查；仍缺这类规则则回到 `ask-me`，不得自行补全。`ask-me` 标注的未决项保持未决，不写成用户已确认的选择。

### 3. 确定并贯彻交付范围

交付范围是本次需求中承担独立职责且会发生改动的产品端、系统、服务或渠道。根据需求目标、业务流程、代码入口和仓库布局识别；事实足以确定时直接采用，无法可靠判断且不同选择会显著改变范围时，提问确认。

### 4. 落地 PRD 文件

新建 PRD 时写入 `docs/scratch/<下一个两位序号>-<中文需求名称>/PRD.md`；更新已有 PRD 时沿用原路径。由 `impl` 转入的局部修正只改被推翻的条款和 Implementation Decisions，不重新启动 `ask-me`；仅当交付范围、能力结构或 Out of Scope 被推翻时才从第 2 步重跑。

## PRD 模板

```markdown
# <功能名称> PRD

## Solution
<用一个段落从用户视角概括整体解决方案，不展开各交付范围的实现细节>

## Scope

### <交付范围 1>
- <该范围的交付内容与职责>

### <交付范围 N>
- <该范围的交付内容与职责>

### 涉及角色
- <使用或办理本功能的角色>

## Out of Scope
<本次明确不做的内容>

## User Stories
1. As a <角色>, I want <功能>, so that <收益>
2. ...

## Requirements
<!-- 先按业务能力分节，再在能力内展开实际涉及的交付范围。 -->

### <能力项 1>

#### <交付范围 1>逻辑
- <按该范围职责写清交互、业务规则、状态、数据、权限、接口或流程边界>

#### <交付范围 N>逻辑
- <按该范围职责写清交互、业务规则、状态、数据、权限、接口或流程边界>

#### 协作契约
- <仅在多个交付范围存在调用顺序、数据交换或失败处理时保留>

### <能力项 2>

...

## Implementation Decisions
### 锁定决策
| 决策项 | 决策值 | 来源 |
| --- | --- | --- |
| ... | ... | 用户确认 / RULE/ <其他>  |

```

## 写法

- **完整可评审**：只读本文就能判断要解决什么问题、由谁使用、交付哪些业务结果，以及明确不做什么。缺少后会改变实现分支、数据口径、状态变化、权限范围或接口契约的规则全部保留。
- **规则可执行**：每条规则能单独判断对错：谁、在什么条件、做什么、结果是什么。字段、日期、状态、数量、权限有口径时写到值。
- **边界一起写**：每个能力覆盖主流程，以及空数据、失败、无权限、重复提交等会改变结果的情况。
- **合成而非转录**：正文是收口后的需求，不是对话、选项或推理过程的摘录。
- **锁定即契约**：Implementation Decisions 只收已确认且会改变交付的选择，并标明来源。
- **产品层表达**：Requirements 写业务行为和规则。具体文件、代码结构、模块改造、实现步骤和代码库能力缺口留给后续实现过程。