context-to-prd git:20261013.be4849dA

Immutable. This exact content never changes and is served at /api/v1/blob/df4330ca0b622246.

---
name: context-to-prd
description: 把已经聊透的需求上下文直接落成 PRD，不做采访。适用于你已经跟 AI 把问题、边界、方案讨论清楚，只差成文的场景；需求还停在口头、边界没问清时改用 requirement-clarify，要复用已有产品体验基线或做增量 PRD 时用 prd-write。产物与 prd-write 完全同构，落在 docs/prd/<feature-name>/prd.md。
---

# 上下文成文

把「已经聊透的需求」直接写成 PRD。**不采访**——你手上已经有足够的上下文，再问一遍是浪费。

## 使用边界

- **适用**：需求已经跟 AI 讨论清楚，问题、用户、范围、边界都有结论，只差落到文档。
- **不适用**：
  - 需求还停在口头、边界没问清 → 先用 `requirement-clarify` 采访一轮
  - 要复用已有产品体验基线，或要做增量 PRD（只写本次变化）→ 用 `prd-write`
  - 要评审已成文的 PRD → 用 `grill-with-prd`

### 与 `prd-write` 的关系（重要）

两者产出**同一套结构**：都以 [template.md](../prd-write/template.md) 的 0–10 节为骨架，
写同一个文件 `prd.md`。差别只在过程：

| | 本 Skill | `prd-write` |
|---|---|---|
| 是否采访 | 不采访 | 不采访 |
| 是否强制读产品体验基线 | 不强制。有就读并写进第 2 节，没有就写「无基线」 | **必须查**。增量模式要靠它写清「复用 / 局部 / 候选 / 偏离」 |
| 典型场景 | 聊透了，一次成文 | 迭代中的功能，要跟已有规范对齐 |

**两个都产出同一个 `prd.md`，不要连着跑。** 写完一个就够了，另一个是用来替补的。

## 开始前

1. 确定功能名，用**小写短横线**（`user-auth`、`payment-flow`）；目标 `docs/prd/<feature-name>/prd.md`。
2. 已有同名 PRD 时先问用户：**更新、另建功能目录、还是保留原文**——不要静默覆盖。
3. 查 `docs/product/<project-name>/`。有基线就读进来写进第 2 节；没有就写「无基线」，
   不要凭空造产品级规则。

## 流程

### 1. 梳理上下文

把这次对话里**已经定下来**的东西挑出来：问题、目标角色、范围、**明确不做**、已知约束、验收口径。

没定下来的**不要替它定**——写进第 9 节「待决问题」，标明归属人。
「明确不做」这一条最容易漏，主动回头找一遍：聊的过程中有没有排除了什么。

### 2. 探索代码库

还没了解代码库就先看一遍。全文使用项目的领域词汇，遵守相关区域已有的架构决策记录（ADR）。

### 3. 梳理模块（本 Skill 的独有产出）

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

> **深度模块**：封装大量功能，对外暴露简单且稳定的接口，便于独立测试。
> 反过来，浅层模块把复杂度摊在外面，测试和改动都会牵连一片。

和用户确认这些模块划分是否符合预期，以及哪些模块需要写测试。

**结论写进第 10 节「交接说明」，不要写进第 7 节**——模块划分和测试范围是实现决策，
第 7 节只写用户能验证的行为。两者混在一起，评审时没人分得清哪条是需求、哪条是做法。

### 4. 成文

以 [template.md](../prd-write/template.md) 的 0–10 节为骨架，写入
`docs/prd/<feature-name>/prd.md`（目录不存在时自动创建）。

- **模式**：没有产品基线、或这是首版/重大模块 → `full`；在迭代中只改一个功能 → `incremental`
- **第 7 节**按用户可验证的行为组织。每条需求写清角色、触发条件、主流程、状态变化、
  权限、异常和验收结果——写法示例见 template 第 7 节
- 事实标来源；合理推断标 `[INFERRED]`；无法确认的进第 9 节
- **不要为了填满模板而编内容**。留空比编错好

## 产物

`docs/prd/<feature-name>/prd.md`，与 `prd-write` 完全同构。

## 不做什么

- 不采访用户（那是 `requirement-clarify` 的活）。
- 不替用户拍板没讨论过的业务决策；只把选项和后果摆清楚。
- 不写代码、不写文件路径——它们很快会过时。
- 不因为「模板这一节空着不好看」而编内容。

## 交付前检查

- [ ] 产物结构与 [template.md](../prd-write/template.md) 的 0–10 节一致
- [ ] 已有 `prd.md` 没有被无意覆盖
- [ ] 对话里没定下来的，都进了第 9 节并写明归属人，没有一条被编成事实
- [ ] 第 7 节写的是用户可验证的行为，不是页面清单或技术任务
- [ ] 写完扫一遍乱码：`grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/`

## 下一步

- 成文后交给 [`grill-with-prd`](../grill-with-prd/) 逐条压测——**这一步别省**，
  自己写的 PRD 自己看不出矛盾。
- 需要外部视觉证据时用 [`web-design-extractor`](../web-design-extractor/)；
  要出独立评审原型时用 [`design-spec-prototyper`](../design-spec-prototyper/)。