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