---
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 的"范围外"部分如果过于简略，追问是否遗漏了重要的排除项。

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

### 确认验收标准

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

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

## 同步更新 PRD

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

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

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

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

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

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

## 审查结束

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

</支撑信息>