to-prd

to-prd 技能概览

to-prd 做什么

to-prd 技能会把当前对话上下文和对代码库的理解整理成一份 PRD，然后发布到项目的 issue tracker。它适合你已经掌握了足够上下文、可以直接开始写作，并且需要的是一份结构化的产品说明，而不是来回追问式的需求访谈。

最适合谁使用

当你在一个现有 repo 里工作，已经知道大致要改什么，并且需要一份能贴合项目术语、ADR 和 tracker 流程的 PRD 时，最适合使用 to-prd 技能。它尤其适合 Skill Authoring 或 agent 驱动的实现流程，因为下一步通常是把内容交给另一个 agent 接手。

它的不同之处

to-prd 的核心差异在于它明确采取“不要采访式追问”的方式：它基于已知信息进行归纳，再用正确的 triage label 把结果推送到 tracker。这样它比通用 prompt 更快，但也更依赖一开始就具备正确的 repo 上下文和 tracker 配置。

如何使用 to-prd 技能

安装与所需上下文

使用 to-prd install 时，先通过项目的 skill installer 安装技能，然后确认 repo 已连接到你要使用的 issue tracker 工作流。这个技能默认 issue tracker 和 triage label 词汇表都已经可用；如果没有，先运行 /setup-matt-pocock-skills。如果跳过这一步，技能可能能产出 PRD 草稿，但无法顺利发布。

如何提示 to-prd 使用

最好的 to-prd usage 会直接给出明确的实现目标、repo 路径或功能区域，以及你已经知道的任何约束。好的输入示例是：“为 apps/web 里新增 OAuth refresh 处理写一份 PRD，使用 repo 的 glossary 和现有 ADR，并发布到 tracker。” 模糊的输入，比如“写一份 auth 的 PRD”，效果就会差很多，因为这个技能的设计目标是归纳，而不是追问。

先检查哪些文件和信号

在依赖输出之前，先查看 SKILL.md，然后再看 repo 的 README.md、AGENTS.md、metadata.json，以及如果存在的话，rules/、resources/、references/ 或 scripts/ 目录。这个仓库里 SKILL.md 是主要来源，所以流程刻意设计得比较轻量；但这也意味着 PRD 的质量会非常依赖你提供的实时代码库上下文。

提升输出质量的实用工作流

当你已经能用产品语言描述变更时，就用这个技能把它转换成包含问题陈述、解决方案和用户故事的 PRD。让它遵循领域 glossary 里的术语和 ADR，并明确说明哪些模块可能会改动、哪些地方需要测试覆盖。如果你在做 to-prd for Skill Authoring，提示词要聚焦在你希望文档化的技能行为上，而不是整个上游仓库。

to-prd 技能常见问题

to-prd 适合所有 PRD 任务吗？

不适合。to-prd 最适用于变化已经理解得足够清楚、可以基于上下文直接写出来的场景。如果你需要做需求发现、产品访谈或市场调研，常规的 prompting 流程会比 to-prd 更合适。

to-prd 和通用 prompt 有什么区别？

通用 prompt 也可以要求写 PRD，但 to-prd 会加入 repo 感知的行为：它会查找 glossary 术语、尊重 ADR、勾勒深层模块，并以 ready-for-agent label 把内容发布到 issue tracker。也就是说，它比自由发挥式的 PRD 请求更偏向实际执行。

初学者可以用吗？

可以，只要他们能提供具体的功能方向，并且理解这个技能不会继续追问。初学者如果在初始请求里写清 repo 区域、用户问题和任何不可妥协的约束，通常能得到最好的结果。

什么时候不该用 to-prd？

当 tracker 不可用、label 词汇不明确，或者功能还在探索阶段时，不要用 to-prd。如果在起草 PRD 前还需要反复做利益相关方访谈，它也不是合适的选择。

如何改进 to-prd 技能

给技能更精准的输入

影响输出质量最大的因素是具体程度。要写清 repo 位置、要解决的问题、预期用户结果，以及平台、性能或发布限制等约束。输入越强，to-prd 产出的 PRD 就越接近真实实现，而不是泛泛而谈。

明确模块与测试预期

这个技能会主动寻找深层模块，并询问哪些模块应该补测试。如果你想要更好的结果，可以直接点名候选模块，说明哪些模块应保持浅层，以及是否有需要抽离的独立逻辑。这样能减少交接摩擦，也让 PRD 对下一个 agent 更可执行。

留意常见失败模式

最常见的失败模式是上下文过于稀薄：PRD 最后会变成一段面向 tracker 的通用说明，而不是能推动决策的方案。另一个风险是术语过时：如果 repo 的 glossary 或 ADR 没有更新，内容就可能不准确。要同时避免这两种问题，就把提示词锚定在当前代码库状态上，并在请求发布前先更新 brief。

从第一版草稿继续迭代

拿到第一版 PRD 后，可以通过收紧用户故事、明确验收边界，以及确认 issue label 和 tracker 目标是否正确来继续优化。对于 to-prd 来说，迭代通常是在消除歧义，而不是扩展范围。