To Spec

---
name: to-spec
description: 将当前对话转化为 spec 并发布到项目的 issue tracker——不访谈，只综合你们已经讨论过的内容。
disable-model-invocation: true
---

本技能获取当前的对话上下文和对代码库的理解，产出一份 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>