关于 to-spec
to-spec 是一项开发技能，可将对话上下文和代码库理解整理为功能规格，并发布到问题跟踪系统。它会确认测试边界，并为已就绪的工作选择实施或拆分路径。
主要功能
- 01综合上下文编写功能规格
- 02探索代码并遵循领域决策
- 03与用户确认测试边界
- 04添加分类标签并发布规格
- 05选择实施交接路径
适用场景
- 01根据现有讨论编写功能规格
- 02实施前定义测试边界
- 03向问题跟踪系统发布就绪事项
- 04拆分需要进一步规划的工作
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-spec确认已加载。
附带文件agents/openai.yaml
详细介绍
此技能会利用当前对话上下文和对代码库的理解来编写规格说明。不要采访用户；只综合你已掌握的信息。
问题跟踪系统和分类标签词汇表应该已提供给你。如果没有，请告知用户运行 /setup-matt-pocock-skills。
流程
-
如果你还不了解代码库的当前状态，请探索仓库。编写规格说明时，始终使用项目的领域词汇表，并遵循你要修改的相关区域中的 ADR。
-
勾勒出你将在哪些边界测试该功能。优先使用现有边界，并选择尽可能高层的边界。如果需要新增边界，请在可行的最高层提出。整个代码库中的边界越少越好——默认每份规格说明一个边界，除非确实存在外部边界，迫使你增加边界。
向用户确认这些边界是否符合他们的预期。
- 使用下方模板编写规格说明，然后将其发布到项目的问题跟踪系统。应用
ready-for-agent分类标签——无需进行额外分类。
问题陈述
从用户的角度描述他们遇到的问题。
解决方案
从用户的角度描述问题的解决方案。
用户故事
一份内容详尽、按编号排列的用户故事列表。每条用户故事均应采用以下格式：
- 作为一名<角色>，我希望获得<功能>，从而<收益>
这份用户故事列表应极其详尽，涵盖该功能的各个方面。
实现决策
列出已作出的实现决策。包括以下内容：
- 将要构建或修改的模块
- 将要修改的模块接口
- 开发者提供的技术说明
- 架构决策
- 架构变更
- API 契约
- 具体交互
不要包含具体文件路径或代码片段，因为它们很快就可能过时。
例外：如果原型生成的代码片段比文字更精确地表达了某项决策（例如状态机、reducer、架构或类型形状），请将其内联到相关决策中，并简要说明它来自原型。只保留体现决策的关键部分，不要包含可运行的演示代码。
测试决策
列出已作出的测试决策。包括：
- 优秀测试的特征（只测试外部行为，不测试实现细节）
- 将要测试的模块
- 测试的先例（即代码库中类似的测试）
范围之外
描述不属于此规格说明范围的事项。
补充说明
有关该功能的其他补充说明。
- 发布后选择执行路径：
- 如果完整规格说明适合在一个实现上下文中完成，并且当前对话足够连贯、可以分叉，则将其标记为
fork → /spec-executor。 - 如果需要分成多个示踪弹切片、并行工作、跨 Agent 交接或压缩上下文，则改为标记为
/to-tickets。不要假装大型规格说明可以直接分叉执行。 - 如果产品决策或测试边界仍未确定，则输出
SPEC NOT READY，并指出缺少的决策。不要启动实现。
- 准备就绪时，以以下精简启动块结尾，以便分叉出的线程能找到最终契约，而无需在多个草稿中猜测：
SPEC READY
- Status: ready for implementation
- Source: <published spec URL or path>
- Repository: <implementation repository>
- Baseline: <current commit, branch, or explicit source baseline>
- Test seam: <highest agreed behavior seam>
- Non-goals: <explicit exclusions>
- External authority: <commit, push, review, deploy, tracker, data, and real-service permissions; default ungranted>
- Next route: fork + /spec-executor | /to-tickets
启动块是已批准规格说明的索引，而非其替代品。不要在启动块中重复完整规格说明。