Grill With Prd

---
name: grill-with-prd
description: 针对 PRD 文档的逐项审查会话，挑战需求的完整性、一致性和可实现性，并将确认的决策同步回 docs/prd/{feature-name}/prd.md。适用于用户想在开始实现前压测 PRD 的场景。
---

<要做什么>

逐一追问 PRD 中的每个需求和决策，直到双方对功能边界、实现路径和验收标准达成共识。每个问题等用户回答后再继续，不一次性抛出所有问题。

如果某个问题可以通过探索代码库来回答，先探索代码库，不要把它抛给用户。

</要做什么>

<支撑信息>

## PRD 文档位置

PRD 文件路径：`docs/prd/{feature-name}/prd.md`

开始前先读取对应的 PRD 文件。如果用户没有指定 feature-name，询问后再继续。

## 审查会话中的行为

### 挑战模糊需求

遇到含糊的用户故事或需求描述时，要求精确化。

> "你说'用户可以管理订单'——管理包含哪些操作？创建、编辑、取消、删除都有吗？"

### 追问边界条件

对每个核心功能，主动构造边界场景来压测需求是否完整。

> "支付失败时，订单状态如何变化？用户能重试吗？重试次数有限制吗？"

### 发现需求冲突

当 PRD 中不同部分存在矛盾时，立刻指出。

> "用户故事第 3 条说用户可以删除草稿，但实现决策里说所有操作都需要审计日志——删除操作也要记录吗？"

### 对照代码库验证

当用户描述某个功能的工作方式时，检查代码库是否与之一致。发现矛盾时明确指出。

> "你说用户登录后会话有效期是 7 天，但代码里的 token 过期时间是 24 小时——以哪个为准？"

### 追问范围外的内容

PRD 的"范围外"部分如果过于简略，追问是否遗漏了重要的排除项。

> "范围外只写了'不支持批量操作'，权限管理呢？这个功能需要区分角色吗？"

### 确认验收标准

对每个用户故事，确认是否有明确的验收标准，否则无法判断实现是否完成。

> "这条用户故事没有验收标准——成功的定义是什么？有性能要求吗？"

## 「指出」不等于「裁决」

这是本 Skill 最容易越界的地方。压测到一半往往要整体重写 PRD，**重写时顺手把发现的冲突一并"解决"掉，看起来是效率，实际是越权。**

分清两类：

| 类型 | 例子 | 你能做的 |
| --- | --- | --- |
| **澄清** | R1 写「显示月付价」、R2 写「默认年付」——只是措辞不一致 | 直接改成一致，**并在交付里说一句改了什么** |
| **裁决** | R1 同时要求「不产生横向滚动」和「卡片可横向滚动」——二选一是个设计决策 | **必须回到用户。** 你可以把选项和后果摆清楚，不能替他选 |

属于业务取舍、设计选择、对外口碑的冲突，一律归第二类。

**如果确实在重写中做了非澄清性的选择**（有时上下文里已经有答案，来不及再问），
那就在交付说明里**单独列出**，别混在「本次审查的主要变更」里一笔带过——
否则用户会以为他点过头。

## 同步更新 PRD

当某个决策在审查中被确认或修正时，立刻更新 PRD 文件，不要攒到最后批量写。

更新范围包括：
- 补充遗漏的用户故事
- 精确化模糊的需求描述
- 补充边界条件的处理方式
- 修正前后矛盾的内容
- 更新实现决策
- 补充或修正范围外的内容

每次更新后告知用户修改了哪里。

## 没有人在旁边回答时（自答模式）

做演示或回归时，可以自己扮演回答方走完一轮：

- 每个问题自己给出结论，但回写 `prd.md` 时标注该结论是**自答**的，不要伪装成用户确认。
- **矛盾、冲突、缺失的验收标准这三类照常报出来**——那正是要压测的东西。自答不等于放行。
- 需要业务拍板的（范围取舍、优先级、价格、对外口径）即使自答也要留在「待决问题」里，写明归属人。
- 交付时把「自答」的部分单独列一遍，让用户一眼看出哪些结论还没经过真人确认。

## 审查结束

当所有主要分支都已追问完毕，且 PRD 已更新到位时，总结本次审查的主要变更，并告知用户 PRD 已可以交付实现。

## 交付前检查

- [ ] 本次回写的每一处，都说清了是「澄清」还是「裁决」
- [ ] 若有裁决性质的选择，已在交付说明里**单独列出**，没有和澄清混在一起
- [ ] 回写后扫一遍中文乱码：`grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/prd.md`

</支撑信息>