用途
to-prd 用于把当前对话上下文和代码库理解转化为一份 PRD（产品需求文档），并将其作为 GitHub issue 提交。当用户希望基于当前上下文创建 PRD 时使用该技能。
该技能明确要求：不要对用户进行访谈，只需综合你已知的信息。
主要能力
- 综合当前对话上下文与代码库理解，生成 PRD。
- 将 PRD 发布到项目 issue 跟踪器，并应用 needs-triage 分诊标签，使其进入正常分诊流程。
- 在撰写过程中使用项目领域词汇表，并遵循所涉及区域的 ADR（架构决策记录）。
- 勾勒完成实现所需构建或修改的主要模块，主动寻找可提取为深模块（deep module）的机会。深模块指以简单、可测试、很少变化的接口封装大量功能的模块，与浅模块相对。
- 与用户确认模块是否符合预期，并确认希望为哪些模块编写测试。
使用方式
前置条件：issue 跟踪器和 triage 标签词汇应已提供；若未提供，需运行 /setup-matt-pocock-skills。
流程：
- 如果尚未进行，先探索仓库以了解代码库当前状态。
- 在 PRD 中全程使用项目领域词汇表，并尊重所涉及区域的 ADR。
- 勾勒完成实现所需构建或修改的主要模块，主动寻找可提取为深模块的机会。
- 与用户确认这些模块是否符合其预期，并确认希望为哪些模块编写测试。
- 使用下方模板撰写 PRD，然后发布到项目 issue 跟踪器。
- 应用 needs-triage 分诊标签，使其进入正常分诊流程。
PRD 模板结构
- 问题陈述（Problem Statement）：从用户视角描述用户面临的问题。
- 解决方案（Solution）：从用户视角描述问题的解决方案。
- 用户故事（User Stories）：一个很长的、编号的用户故事列表，每条格式为“作为 <角色>，我想要 <功能>，以便 <价值>”。该列表应极其详尽，覆盖功能的所有方面。
- 实现决策（Implementation Decisions）：已做出的实现决策列表，可包括将构建/修改的模块、这些模块将被修改的接口、来自开发者的技术澄清、架构决策、模式变更、API 契约、具体交互。不要包含具体文件路径或代码片段，因为它们可能很快过时。
- 测试决策（Testing Decisions）：已做出的测试决策列表，包括对什么是好测试的描述（只测试外部行为，不测试实现细节）、将测试哪些模块、测试的先例（即代码库中类似类型的测试）。
- 范围外（Out of Scope）：描述本 PRD 范围之外的事项。
- 补充说明（Further Notes）：关于该功能的任何进一步说明。
适用场景
- 用户希望基于当前对话上下文创建 PRD。
- 需要将对话中形成的需求综合为结构化文档并提交为 GitHub issue。
- 需要为某项功能规划模块划分、实现决策与测试决策，并进入分诊流程。
限制
- 该技能不进行用户访谈，只综合已有信息。
- 依赖已配置的 issue 跟踪器和 triage 标签词汇；若未配置，需先运行 /setup-matt-pocock-skills。
- PRD 中不应包含具体文件路径或代码片段。
- 关于收费、价格、平台支持范围等信息，资料中暂未提供。