用途
to-prd 用于把当前对话中已经讨论过的内容综合成一份 PRD（产品需求文档），并发布到项目的 issue tracker。它的定位是“不做访谈，只做综合”——即不向用户提问，而是直接利用已有的对话上下文和代码库理解来产出文档。
主要能力
- 从当前对话上下文与代码库理解中生成 PRD。
- 探索仓库以了解代码库当前状态。
- 在 PRD 中贯穿使用项目领域词汇表（domain glossary），并尊重所涉及区域的 ADR。
- 勾勒将要测试该功能的接缝（seams）：优先使用现有接缝，使用尽可能高的接缝；若需要新接缝，则在尽可能高的位置提出；接缝越少越好，理想数量为一个。
- 与用户确认这些接缝是否符合其预期。
- 按指定模板撰写 PRD，并发布到项目 issue tracker，打上 ready-for-agent 分类标签，无需额外分类。
使用方式
该技能会读取当前对话上下文与代码库理解，然后按以下流程执行：
- 如果尚未了解代码库，先探索仓库以理解当前状态。
- 在 PRD 中使用项目领域词汇表，并尊重相关 ADR。
- 勾勒测试接缝，优先复用现有接缝、使用最高接缝；如需新接缝，在尽可能高的位置提出；接缝越少越好，理想为一个。
- 与用户确认接缝是否符合预期。
- 使用模板撰写 PRD，并发布到项目 issue tracker，打上 ready-for-agent 分类标签。
PRD 模板包含以下部分：
- Problem Statement（问题陈述）：从用户视角描述用户面临的问题。
- Solution（解决方案）：从用户视角描述问题的解决方案。
- User Stories（用户故事）：一个很长的、带编号的用户故事列表，每条格式为“As an , I want a , so that ”。该列表应极其详尽，覆盖功能的所有方面。
- Implementation Decisions（实现决策）：列出已做出的实现决策，可包括将构建/修改的模块、这些模块将被修改的接口、来自开发者的技术澄清、架构决策、schema 变更、API 契约、具体交互。不要包含具体文件路径或代码片段，因为它们可能很快过时。例外：如果原型产出的片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型形状），可将其内联在相关决策中，并简要注明来自原型；只保留决策密集的部分，不是可运行 demo，只是重要部分。
- Testing Decisions（测试决策）：列出已做出的测试决策，包括对什么是好测试的描述（只测试外部行为，不测试实现细节）、将测试哪些模块、测试的先例（即代码库中类似类型的测试）。
- Out of Scope（范围外）：描述本 PRD 范围之外的事项。
- Further Notes（补充说明）：关于该功能的任何进一步说明。
前置条件：issue tracker 与分类标签词汇应已提供；如果没有，需先运行 /setup-matt-pocock-skills。
适用场景
适用于已经就某个功能进行过讨论、希望把讨论内容快速固化为 PRD 并发布到项目 issue tracker 的场合。尤其适合不想再经历一轮访谈、希望直接综合已有信息的团队或个人。
限制
- 不进行用户访谈，只综合已有内容。
- 需要已提供 issue tracker 与分类标签词汇，否则需先运行 /setup-matt-pocock-skills。
- 实现决策中不应包含具体文件路径或代码片段（原型片段例外）。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。