关于 to-spec
to-spec 是一项将现有对话上下文和代码库理解整理为功能规格并发布到 issue 跟踪器的技能，面向需要把需求交给开发流程的团队。它要求确认测试接缝，并使用详尽的用户故事及实现、测试决策结构。
主要功能
- 01综合对话与代码库信息
- 02确认功能测试接缝
- 03按固定模板编写规格
- 04覆盖用户故事和实现决策
- 05发布规格并添加分类标签
适用场景
- 01将讨论中的功能需求整理为规格
- 02为开发任务明确测试范围
- 03把实现约束和范围外事项记录到 issue
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-spec确认已加载。
附带文件agents/openai.yaml
详细介绍
来自项目 README本技能获取当前的对话上下文和对代码库的理解，产出一份 spec。不要盘问用户——只综合你已经知道的内容。
issue 跟踪器和分类标签词汇应该已经提供给你了——如果没有，告诉用户运行 /setup-matt-pocock-skills。
流程
-
如果还没探索过，先探索仓库，了解代码库的当前状态。整个 spec 都使用项目的领域词汇表术语，并尊重你正在触碰的区域的任何 ADR。
-
勾勒出你将测试该功能的接缝。已有接缝应优先于新接缝。用尽可能高的接缝。如果需要新接缝，在你能达到的最高点提出。代码库中的接缝越少越好——理想数量是一个。
与用户确认这些接缝符合他们的预期。
-
用下面的模板写 spec，然后发布到项目的 issue 跟踪器。打上
ready-for-agent分类标签——不需要再做分类。
问题陈述
用户正面临的问题，从用户的角度描述。
解决方案
问题的解决方案，从用户的角度描述。
用户故事
一个长长的、编号的用户故事列表。每个用户故事遵循以下格式：
- 作为一个<角色>，我想要<功能>，以便<收益>
这份用户故事列表应该极其详尽，覆盖该功能的方方面面。
实现决策
已作出的实现决策列表。可以包括：
- 将要构建/修改的模块
- 将被修改的那些模块的接口
- 来自开发者的技术澄清
- 架构决策
- Schema 变更
- API 契约
- 具体交互
不要包含具体的文件路径或代码片段。它们可能很快就过时了。
例外：如果原型产出了比散文更精确地编码某个决策的片段（状态机、reducer、schema、类型形态），把它内联进相关决策中，并简要注明它来自原型。裁到决策密集的部分——不是可运行的演示，只是重要的片段。
测试决策
已作出的测试决策列表。包括：
- 什么构成好测试的描述（只测外部行为，不测实现细节）
- 哪些模块将被测试
- 测试的先例（即代码库中类似的测试类型）
范围外
本 spec 范围之外的内容描述。
补充说明
关于该功能的任何补充说明。