关于 to-spec
将对话上下文和代码库理解整理为功能规格，并发布到项目问题跟踪器的技能。它强调测试切入点、领域词汇和结构化文档，且不采访用户。
主要功能
- 01综合上下文生成规格
- 02探索代码库与领域术语
- 03提出测试切入点供用户确认
- 04添加分诊标签并发布规格
适用场景
- 01根据当前对话起草功能规格
- 02准备并发布问题跟踪器规格
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-spec确认已加载。
附带文件agents/openai.yaml
详细介绍
此技能会利用当前对话上下文和对代码库的理解来编写规格说明。不要采访用户；只综合你已掌握的信息。
问题跟踪系统和分类标签词汇应已提供给你。如果没有，请告诉用户运行 /setup-matt-pocock-skills。
流程
-
如果尚未了解代码库的当前状态，请探索仓库。编写规格说明时始终使用项目的领域术语表，并遵循你所涉及领域的 ADR。
-
梳理你将通过哪些边界来测试此功能。优先使用现有边界，并选择层级最高的边界。如果需要新增边界，请尽可能在最高层级提出。跨越代码库的边界越少越好——理想数量是一个。
请向用户确认这些边界是否符合他们的预期。
- 使用下方模板编写规格说明，然后发布到项目的问题跟踪系统。添加
ready-for-agent分类标签——无需额外分类。
问题陈述
从用户的角度描述他们遇到的问题。
解决方案
从用户的角度描述问题的解决方案。
用户故事
一份较长的编号用户故事列表。每条用户故事都应采用以下格式：
- 作为一名<角色>，我希望拥有一项<功能>，以便<收益>
这份用户故事列表应尽可能详尽，并涵盖此功能的所有方面。
实现决策
已作出的实现决策列表。内容可包括：
- 将要构建/修改的模块
- 将要修改的模块接口
- 开发者提供的技术说明
- 架构决策
- 架构变更
- API 合约
- 具体交互
不要包含具体文件路径或代码片段。它们很快就可能过时。
例外：如果原型生成的代码片段比文字描述更精确地表达了某项决策（例如状态机、reducer、架构或类型结构），可将其内嵌在相关决策中，并简要注明该内容来自原型。只保留能体现决策的部分，不要放入可运行的演示代码，只需保留重要内容。
测试决策
已作出的测试决策列表。请包括：
- 优秀测试的特点说明（只测试外部行为，不测试实现细节）
- 将进行测试的模块
- 测试的先例（即代码库中类似的测试）
范围之外
描述不属于本规格说明范围的事项。
补充说明
有关此功能的其他说明。
4. 发布语言
规格说明正文使用英文。对于个人仓库（远程仓库所有者与 gh api user --jq .login 的结果一致；无法确认时视为外部仓库），请在规格说明问题上单独发布一条评论——作为主要内容——并包含 ## Chinese Summary (non-authoritative) 小节，总结要点。摘要只应放在规格说明问题上；切勿将其添加到子问题或后续问题中。