to-spec

本技能获取当前的对话上下文和对代码库的理解，产出一份 spec。不要盘问用户——只综合你已经知道的内容。

issue 跟踪器和分类标签词汇应该已经提供给你了——如果没有，告诉用户运行 /setup-matt-pocock-skills。

流程

1. 如果还没探索过，先探索仓库，了解代码库的当前状态。整个 spec 都使用项目的领域词汇表术语，并尊重你正在触碰的区域的任何 ADR。

2. 勾勒出你将测试该功能的接缝。已有接缝应优先于新接缝。用尽可能高的接缝。如果需要新接缝，在你能达到的最高点提出。代码库中的接缝越少越好——理想数量是一个。

   与用户确认这些接缝符合他们的预期。

3. 用下面的模板写 spec，然后发布到项目的 issue 跟踪器。打上 ready-for-agent 分类标签——不需要再做分类。

<spec-template>

问题陈述

用户正面临的问题，从用户的角度描述。

解决方案

问题的解决方案，从用户的角度描述。

用户故事

一个长长的、编号的用户故事列表。每个用户故事遵循以下格式：

1. 作为一个<角色>，我想要<功能>，以便<收益>

<user-story-example> 1. 作为手机银行客户，我想看到我账户的余额，以便能对消费做出更明智的决定 </user-story-example>

这份用户故事列表应该极其详尽，覆盖该功能的方方面面。

实现决策

已作出的实现决策列表。可以包括：

• 将要构建/修改的模块
• 将被修改的那些模块的接口
• 来自开发者的技术澄清
• 架构决策
• Schema 变更
• API 契约
• 具体交互

不要包含具体的文件路径或代码片段。它们可能很快就过时了。

例外：如果原型产出了比散文更精确地编码某个决策的片段（状态机、reducer、schema、类型形态），把它内联进相关决策中，并简要注明它来自原型。裁到决策密集的部分——不是可运行的演示，只是重要的片段。

测试决策

已作出的测试决策列表。包括：

• 什么构成好测试的描述（只测外部行为，不测实现细节）
• 哪些模块将被测试
• 测试的先例（即代码库中类似的测试类型）

范围外

本 spec 范围之外的内容描述。

补充说明

关于该功能的任何补充说明。

</spec-template>