PRD 给 Agent 用，重点不是写得像文档，而是能继续执行

用户给出的 to-prd 链接在当前 mattpocock/skills 仓库里已经找不到对应目录；仓库里实际存在的是相邻的 to-spec、to-tickets、writing-great-skills 等 Skill。这个变化反而说明了一个更重要的点：成熟的 AI 工程流程，不该停在“把想法写成 PRD”这一层，而是要把需求、测试缝、实现决策和可交付 ticket 串起来。

to-spec 的核心判断很直接：不要再采访用户，而是把已有对话和代码库状态综合成一份规格文档。它要求先理解代码库和领域词汇，再决定测试缝，最后写 Problem Statement、Solution、User Stories、Implementation Decisions、Testing Decisions、Out of Scope。

PRD 不该只是产品文档，而是工程入口

很多团队的 PRD 问题不是写得不够长，而是和代码库脱节。需求写完后，工程师还要重新猜模块边界、测试位置、数据结构和验收口径。to-spec 这类 Skill 的价值，是把规格文档写成 Agent 能继续执行的入口，而不是写成一篇漂亮说明。

它特别强调不要在文档里塞容易过期的文件路径和代码片段，而是记录稳定的实现决策、接口边界、测试原则和范围排除。这个取舍很工程化：规格要能指导实现，但不能因为一次重构就失效。

测试缝是 PRD 到实现之间最容易缺的一环

to-spec 要求先想清楚测试会卡在哪个 seam。已有 seam 优先，新 seam 要尽量高层、数量越少越好。这个要求比“写用户故事”更关键，因为它决定后续 Agent 是否能在可验证边界里工作。

如果需求没有测试缝，后续拆 ticket 时就容易横切成“先改数据库、再改 API、再改 UI”，每一步都不可演示。相反，先确定高层验证点，后续 to-tickets 才能拆成 tracer bullet：每张票都穿过必要层次，完成后能独立验证。

Skill 化的需求流程适合 Agent 团队

当一个团队开始让多个 Agent 分别写 spec、拆 ticket、实现、review，最怕的是每一步都重新解释上下文。Skill 的作用是把交接格式固定下来：spec 里写哪些决策，ticket 里写哪些阻塞边，review 看哪些验收标准。