context-to-prd · diff
git:20261013.60e8978 to git:20261013.be4849d
63 added, 47 removed. Audit A to A.
---
name: context-to-prd
- description: 根据当前对话上下文和代码库理解生成 PRD，保存到 docs/prd/{feature-name}/prd.md。不采访用户，直接综合已知信息。
+ description: 把已经聊透的需求上下文直接落成 PRD，不做采访。适用于你已经跟 AI 把问题、边界、方案讨论清楚，只差成文的场景；需求还停在口头、边界没问清时改用 requirement-clarify，要复用已有产品体验基线或做增量 PRD 时用 prd-write。产物与 prd-write 完全同构，落在 docs/prd/<feature-name>/prd.md。
---
- 本 skill 基于当前对话上下文和代码库现状生成 PRD。不主动采访用户——直接综合你已掌握的信息。
-
- ## 流程
-
- ### 1. 探索代码库
+ # 上下文成文
- 如果尚未了解代码库，先探索当前状态。在整个 PRD 中使用项目的领域词汇，并遵守相关区域已有的架构决策记录（ADR）。
+ 把「已经聊透的需求」直接写成 PRD。**不采访**——你手上已经有足够的上下文，再问一遍是浪费。
- ### 2. 梳理模块
+ ## 使用边界
- 梳理需要新建或修改的主要模块。主动寻找可以独立测试的深度模块机会。
+ - **适用**：需求已经跟 AI 讨论清楚，问题、用户、范围、边界都有结论，只差落到文档。
+ - **不适用**：
+ - 需求还停在口头、边界没问清 → 先用 `requirement-clarify` 采访一轮
+ - 要复用已有产品体验基线，或要做增量 PRD（只写本次变化）→ 用 `prd-write`
+ - 要评审已成文的 PRD → 用 `grill-with-prd`
- **深度模块**（相对于浅层模块）：封装大量功能，对外暴露简单且稳定的接口，便于独立测试。
+ ### 与 `prd-write` 的关系（重要）
- 与用户确认这些模块是否符合预期，并确认哪些模块需要编写测试。
+ 两者产出**同一套结构**：都以 [template.md](../prd-write/template.md) 的 0–10 节为骨架，
+ 写同一个文件 `prd.md`。差别只在过程：
- ### 3. 编写并保存 PRD
+ | | 本 Skill | `prd-write` |
+ |---|---|---|
+ | 是否采访 | 不采访 | 不采访 |
+ | 是否强制读产品体验基线 | 不强制。有就读并写进第 2 节，没有就写「无基线」 | **必须查**。增量模式要靠它写清「复用 / 局部 / 候选 / 偏离」 |
+ | 典型场景 | 聊透了，一次成文 | 迭代中的功能，要跟已有规范对齐 |
- 按照下方模板编写 PRD，保存到 `docs/prd/{feature-name}/prd.md`（目录不存在时自动创建）。
+ **两个都产出同一个 `prd.md`，不要连着跑。** 写完一个就够了，另一个是用来替补的。
- `{feature-name}` 使用小写短横线命名，例如 `user-auth`、`payment-flow`。
+ ## 开始前
- <prd-template>
+ 1. 确定功能名，用**小写短横线**（`user-auth`、`payment-flow`）；目标 `docs/prd/<feature-name>/prd.md`。
+ 2. 已有同名 PRD 时先问用户：**更新、另建功能目录、还是保留原文**——不要静默覆盖。
+ 3. 查 `docs/product/<project-name>/`。有基线就读进来写进第 2 节；没有就写「无基线」，
+ 不要凭空造产品级规则。
- ## 问题陈述
+ ## 流程
- 从用户视角描述当前面临的问题。
+ ### 1. 梳理上下文
- ## 解决方案
+ 把这次对话里**已经定下来**的东西挑出来：问题、目标角色、范围、**明确不做**、已知约束、验收口径。
- 从用户视角描述解决方案。
+ 没定下来的**不要替它定**——写进第 9 节「待决问题」，标明归属人。
+ 「明确不做」这一条最容易漏，主动回头找一遍：聊的过程中有没有排除了什么。
- ## 用户故事
+ ### 2. 探索代码库
- 详细的编号用户故事列表，覆盖功能的所有方面。每条格式：
+ 还没了解代码库就先看一遍。全文使用项目的领域词汇，遵守相关区域已有的架构决策记录（ADR）。
- 1. 作为 <角色>，我希望 <功能>，以便 <收益>
+ ### 3. 梳理模块（本 Skill 的独有产出）
- <示例>
- 1. 作为移动端银行用户，我希望能查看账户余额，以便做出更合理的消费决策
- </示例>
+ 梳理需要新建或修改的主要模块，主动找**可独立测试的深度模块**机会：
- 列表应尽量详尽，覆盖所有使用场景。
+ > **深度模块**：封装大量功能，对外暴露简单且稳定的接口，便于独立测试。
+ > 反过来，浅层模块把复杂度摊在外面，测试和改动都会牵连一片。
- ## 实现决策
+ 和用户确认这些模块划分是否符合预期，以及哪些模块需要写测试。
- 已确定的实现决策列表，可包括：
+ **结论写进第 10 节「交接说明」，不要写进第 7 节**——模块划分和测试范围是实现决策，
+ 第 7 节只写用户能验证的行为。两者混在一起，评审时没人分得清哪条是需求、哪条是做法。
- - 需要新建或修改的模块
- - 相关模块接口的变更
- - 开发者的技术澄清
- - 架构决策
- - 数据库 Schema 变更
- - API 契约
- - 关键交互逻辑
+ ### 4. 成文
- 不要包含具体文件路径或代码片段，它们很快会过时。
+ 以 [template.md](../prd-write/template.md) 的 0–10 节为骨架，写入
+ `docs/prd/<feature-name>/prd.md`（目录不存在时自动创建）。
- 例外：如果原型产出的代码片段能比文字更精确地表达某个决策（状态机、reducer、schema、类型定义），可以内联到对应决策中，并注明来自原型。只保留决策关键部分，不要完整的可运行示例。
+ - **模式**：没有产品基线、或这是首版/重大模块 → `full`；在迭代中只改一个功能 → `incremental`
+ - **第 7 节**按用户可验证的行为组织。每条需求写清角色、触发条件、主流程、状态变化、
+ 权限、异常和验收结果——写法示例见 template 第 7 节
+ - 事实标来源；合理推断标 `[INFERRED]`；无法确认的进第 9 节
+ - **不要为了填满模板而编内容**。留空比编错好
- ## 测试决策
+ ## 产物
- 已确定的测试决策列表，包括：
+ `docs/prd/<feature-name>/prd.md`，与 `prd-write` 完全同构。
- - 好测试的标准（只测试外部行为，不测试实现细节）
- - 需要编写测试的模块
- - 测试参考（代码库中类似的测试示例）
+ ## 不做什么
- ## 范围外
+ - 不采访用户（那是 `requirement-clarify` 的活）。
+ - 不替用户拍板没讨论过的业务决策；只把选项和后果摆清楚。
+ - 不写代码、不写文件路径——它们很快会过时。
+ - 不因为「模板这一节空着不好看」而编内容。
- 本 PRD 明确不包含的内容。
+ ## 交付前检查
- ## 补充说明
+ - [ ] 产物结构与 [template.md](../prd-write/template.md) 的 0–10 节一致
+ - [ ] 已有 `prd.md` 没有被无意覆盖
+ - [ ] 对话里没定下来的，都进了第 9 节并写明归属人，没有一条被编成事实
+ - [ ] 第 7 节写的是用户可验证的行为，不是页面清单或技术任务
+ - [ ] 写完扫一遍乱码：`grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/`
- 关于本功能的其他备注。
+ ## 下一步
- </prd-template>
+ - 成文后交给 [`grill-with-prd`](../grill-with-prd/) 逐条压测——**这一步别省**，
+ 自己写的 PRD 自己看不出矛盾。
+ - 需要外部视觉证据时用 [`web-design-extractor`](../web-design-extractor/)；
+ 要出独立评审原型时用 [`design-spec-prototyper`](../design-spec-prototyper/)。