关于 to-spec
用于根据当前对话和代码库理解撰写功能规格说明的技能，不通过访谈收集新需求。它整理测试边界，并在确认后按模板将规格发布到项目工单跟踪器。
主要功能
- 01综合对话与代码库上下文
- 02梳理并确认测试边界
- 03按模板编写功能规格
- 04记录实现与测试决策
- 05发布规格并添加就绪标签
适用场景
- 01把已知需求整理成功能规格
- 02明确功能测试的高层边界
- 03记录架构、接口及范围决策
- 04将规格发布到项目工单跟踪器
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/to-spec确认已加载。
附带文件agents/openai.yaml
详细介绍
此 skill 会提取当前对话的上下文和对代码库的理解，并据此生成一份 spec。不要采访用户——只需综合已有信息。
Issue 跟踪器和 triage 标签词汇表应该已提供给你；如果没有，请运行 /setup-leandrocfe-skills。
流程
-
探索仓库，了解代码库的当前状态（如果尚未完成）。在整份 spec 中使用项目领域词汇表中的术语，并遵循你正在处理的领域内的任何 ADR。
-
勾勒出要用于测试此功能的 seam。优先使用已有 seam。尽可能使用最高层级的 seam。如果需要新增 seam，应尽可能在最高层级提出。散布在代码库中的 seam 越少越好——理想数量是一个。
向用户确认这些 seam 是否符合预期。
- 使用下面的模板编写 spec，并发布到项目的 issue 跟踪器。应用 triage 标签
ready-for-agent——无需进行额外 triage。
问题陈述
从用户的角度描述用户遇到的问题。
解决方案
从用户的角度描述问题的解决方案。
用户故事
列出大量编号用户故事。每个用户故事都应采用以下格式：
- 作为 <角色>，我想要 <功能>，以便 <收益>
这份用户故事列表应极其详尽，并涵盖功能的所有方面。
实现决策
列出已做出的实现决策。可以包括：
- 将要构建或修改的模块
- 将要修改的模块接口
- 开发者的技术说明
- 架构决策
- Schema 变更
- API 契约
- 具体交互
不要包含具体文件路径或代码片段。它们很快就可能过时。
例外：如果 prototype 生成的代码片段比文字描述更精确地表达了一项决策（状态机、reducer、schema、类型格式），则将其包含在相关决策中，并简要注明该内容来自 prototype。只保留富含决策信息的部分——它不是可运行的演示，只需包含重要内容。
测试决策
列出已做出的测试决策。包括：
- 对优秀测试的描述（只测试外部行为，不测试实现细节）
- 将要测试的模块
- 测试先例（即代码库中已有的类似测试类型）
不在范围内
描述此 spec 不涉及的内容。
补充说明
与此功能相关的任何其他说明。
评论
支持 Markdown