Appearance
to-prd 适合在你已经和 AI 讨论了一轮方案以后使用。它把当前上下文整理成 PRD：问题、方案、用户故事、实现决策、测试决策和不做什么。重点不是重新问一遍需求，而是把已经达成的理解固定下来。
AI 怎么把对话整理成 PRD：to-prd 技能适合什么时候用
很多 PRD 写得慢，是因为讨论和文档分开了。
你已经和 AI 聊了半小时：为什么要做、哪些功能先做、哪些接口会动、哪些测试要补。等真正要写 PRD 时，又从空白文档开始整理。
to-prd 这个技能的思路是：不要重新采访用户，直接综合当前对话和代码理解。
它适合“已经讨论过”的需求
to-prd 不适合在你只有一句模糊想法时直接用。
更适合的时机是：
- 你已经说明了问题背景。
- AI 已经看过相关代码。
- 方案方向大致确定。
- 有一些实现和测试取舍需要记录。
如果需求还没问清，先用 grill-with-docs 或 需求澄清：Spec。
PRD 要记录决策，不只是功能清单
很多 AI 写 PRD 会变成功能列表：页面 A、按钮 B、接口 C。
to-prd 更强调决策：
- 这次解决什么用户问题。
- 哪些模块会被修改。
- 采用哪些接口或数据结构。
- 哪些测试是必须的。
- 哪些事情明确不做。
这些内容以后会影响 Issue 拆分、代码实现和验收。
不要把 PRD 写成技术细节堆叠
PRD 里可以记录实现决策，但不应该塞满文件路径和代码片段。
文件路径会变，代码也会变。PRD 更适合记录稳定的信息：为什么这样做、哪些模块参与、哪些行为必须被验证。
可以这样要求 AI：
md
请基于当前对话整理一份 PRD。
不要重新采访我，不要补充没有讨论过的功能。
需要包含：问题、方案、用户故事、实现决策、测试决策、Out of Scope。
不要写具体文件路径和代码片段。这能避免 PRD 变成半份设计文档、半份实现清单。
和 Issue tracker 的关系
Matt Pocock 这套技能默认 PRD 会发布到 Issue tracker。
这对团队协作很有用：PRD 不是孤立文档，而是后续 to-issues、triage、实现和验收的上游。
个人项目也可以用本地 Markdown 代替 Issue tracker。关键不是工具，而是让 PRD 进入后续工作流。
你可能还需要
同类技能：
如果你已经和 AI 把方案聊清楚了，下一步不是直接写代码。先把共识整理成 PRD，后面才容易拆任务。