to-spec

to-spec 是一个用于把当前对话转化为规格说明（spec）并发布到项目 issue 跟踪器的技能。它的核心特点是：不进行用户访谈，而是直接综合你已经讨论过的内容以及代码库理解来生成规格。

用途

该技能适用于需要将对话中已经形成的需求、决策和上下文快速固化为可跟踪规格的场景。它不会向用户提问，而是基于现有信息进行综合。

主要能力

从当前对话上下文和代码库理解生成规格。
使用项目领域词汇表（domain glossary）中的术语。
遵循所涉及区域的 ADR（架构决策记录）。
确定测试接缝（seams）：优先使用已有接缝，使用尽可能高的接缝；如需新接缝，在尽可能高的位置提出；接缝越少越好，理想数量为一个。
与用户确认接缝是否符合预期。
按模板撰写规格并发布到项目 issue 跟踪器。
应用 ready-for-agent 标签，无需额外 triage。
如果规格细化自已有父 issue（例如对话从 epic 开始，或用户提供了其引用），则使用 issue-tracker 文档中的机制将发布的规格作为该父 issue 的原生子 issue 链接，使其出现在父 issue 的子 issue 列表中，而不仅仅是在文字中提及。

使用方式

前置条件：issue 跟踪器和 triage 标签词汇应已提供。如果没有，需告知用户运行 /setup-matt-pocock-skills。

流程：

规格模板包含以下部分：

问题陈述（Problem Statement）：从用户视角描述用户面临的问题。
解决方案（Solution）：从用户视角描述问题的解决方案。
用户故事（User Stories）：一个很长的、编号的用户故事列表，每个格式为“作为……，我想要……，以便……”。该列表应极其详尽，覆盖功能的所有方面。
实现决策（Implementation Decisions）：已做出的实现决策列表，可包括将构建/修改的模块、这些模块将被修改的接口、来自开发者的技术澄清、架构决策、模式变更、API 契约、具体交互。不要包含具体文件路径或代码片段，因为它们可能很快过时。例外：如果原型产生的片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型形状），则将其内联在相关决策中，并简要注明来自原型；只保留决策丰富的部分，而非可运行演示。
测试决策（Testing Decisions）：已做出的测试决策列表，包括好测试的描述（只测试外部行为，不测试实现细节）、将测试哪些模块、测试的先例（即代码库中类似类型的测试）。
范围外（Out of Scope）：描述该规格范围之外的事项。
补充说明（Further Notes）：关于该功能的任何进一步说明。

适用场景

适用于已有对话上下文和代码库理解、需要快速生成并发布规格到 issue 跟踪器的开发工作流，尤其适合从 epic 或已有父 issue 细化出子规格的场景。

限制

技能介绍