About to-spec
to-spec is a skill for turning existing conversation context and codebase understanding into a feature specification posted to an issue tracker. It is intended for teams preparing requirements for development, with an explicit check of testing seams and detailed sections for user stories and implementation and test decisions.
Key features
- 01Synthesize conversation and codebase context
- 02Confirm seams for feature testing
- 03Write specifications from a fixed template
- 04Detail user stories and implementation decisions
- 05Post the spec with a triage label
Use cases
- 01Turn feature discussions into specifications
- 02Define test scope for development work
- 03Record implementation constraints and out-of-scope items in an issue
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/to-specin Claude Code to confirm it loaded.
Bundled filesagents/openai.yaml
Details
From the project README本技能获取当前的对话上下文和对代码库的理解，产出一份 spec。不要盘问用户——只综合你已经知道的内容。
issue 跟踪器和分类标签词汇应该已经提供给你了——如果没有，告诉用户运行 /setup-matt-pocock-skills。
流程
-
如果还没探索过，先探索仓库，了解代码库的当前状态。整个 spec 都使用项目的领域词汇表术语，并尊重你正在触碰的区域的任何 ADR。
-
勾勒出你将测试该功能的接缝。已有接缝应优先于新接缝。用尽可能高的接缝。如果需要新接缝，在你能达到的最高点提出。代码库中的接缝越少越好——理想数量是一个。
与用户确认这些接缝符合他们的预期。
-
用下面的模板写 spec，然后发布到项目的 issue 跟踪器。打上
ready-for-agent分类标签——不需要再做分类。
问题陈述
用户正面临的问题，从用户的角度描述。
解决方案
问题的解决方案，从用户的角度描述。
用户故事
一个长长的、编号的用户故事列表。每个用户故事遵循以下格式：
- 作为一个<角色>，我想要<功能>，以便<收益>
这份用户故事列表应该极其详尽，覆盖该功能的方方面面。
实现决策
已作出的实现决策列表。可以包括：
- 将要构建/修改的模块
- 将被修改的那些模块的接口
- 来自开发者的技术澄清
- 架构决策
- Schema 变更
- API 契约
- 具体交互
不要包含具体的文件路径或代码片段。它们可能很快就过时了。
例外：如果原型产出了比散文更精确地编码某个决策的片段（状态机、reducer、schema、类型形态），把它内联进相关决策中，并简要注明它来自原型。裁到决策密集的部分——不是可运行的演示，只是重要的片段。
测试决策
已作出的测试决策列表。包括：
- 什么构成好测试的描述（只测外部行为，不测实现细节）
- 哪些模块将被测试
- 测试的先例（即代码库中类似的测试类型）
范围外
本 spec 范围之外的内容描述。
补充说明
关于该功能的任何补充说明。