用途
to-spec 用于把当前对话上下文与对代码库的理解综合成一份规格说明（spec），并发布到项目的问题跟踪器。它明确要求不要访谈用户，只综合已经知道的内容。
主要能力
- 从当前对话和代码库理解中生成 spec。
- 使用项目领域词汇表（domain glossary）中的词汇。
- 尊重所涉及区域的 ADR。
- 规划测试接缝（seams）：优先使用现有接缝，使用尽可能高的接缝；若需要新接缝，在尽可能高的位置提出；接缝越少越好，理想数量为一个。
- 若接缝已在对话中确定，则记录并继续；否则在发布前与用户确认这些接缝是否符合预期。
- 按模板撰写 spec 并发布到项目问题跟踪器。
- 应用 ready-for-agent 分类标签，无需额外分类。
使用方式
问题跟踪器和分类标签词汇应已提供。如果没有，提示用户运行 /setup-matt-pocock-skills。
流程：
- 如果尚未了解，先探索仓库以理解代码库当前状态。
- 在 spec 中全程使用项目领域词汇，并尊重所涉及区域的 ADR。
- 规划测试接缝：优先现有接缝，使用最高接缝；需要新接缝时在最高点提出；接缝越少越好，理想为一个。
- 若接缝已由对话确定，记录并继续；否则先与用户确认是否符合预期。
- 按模板撰写 spec，然后发布到项目问题跟踪器。
- 应用 ready-for-agent 分类标签。
Spec 模板结构
- Problem Statement：从用户视角描述用户面临的问题。
- Solution：从用户视角描述问题的解决方案。
- User Stories：按范围大小编号的用户故事列表，格式为“As an , I want a , so that ”。覆盖功能所需的用户可见行为和边界情况，不要用推测性变体填充列表。
- Implementation Decisions：已做出的实现决策列表，可包括将构建/修改的模块、这些模块将被修改的接口、来自开发者的技术澄清、架构决策、schema 变更、API 契约、具体交互。不要包含具体文件路径或代码片段，因为它们可能很快过时。例外：如果原型产出的片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型形状），可内联在相关决策中，并简要注明来自原型；只保留决策密集部分，不是可运行演示。
- Testing Decisions：已做出的测试决策列表，包括好测试的描述（只测试外部行为，不测试实现细节）、将测试哪些模块、测试的先例（代码库中类似类型的测试）。
- Out of Scope：本 spec 范围外的事项描述。
- Further Notes：关于该功能的任何进一步说明。
适用场景
适用于已经就某个功能进行过讨论、需要把讨论内容固化为可发布规格说明并进入问题跟踪器流程的场景。
限制
- 不进行用户访谈，只综合已有内容。
- 需要预先提供问题跟踪器和分类标签词汇，否则需运行 /setup-matt-pocock-skills。
- 实现决策中不应包含具体文件路径或代码片段（原型决策片段除外）。
- 用户故事不应填充推测性变体。
- 关于收费、价格、平台、效果等事实，资料未提供。