---
name: to-spec
description: 将当前对话与讨论成果综合整理为一份可实施规格，并发布到项目的 issue 追踪器。不再追加访谈，只综合已有讨论。
disable-model-invocation: true
---

本 skill 根据当前对话上下文和对代码库的理解产出规格。**不要**访谈用户，只综合你已经掌握的信息。

issue 追踪器和分诊标签词汇应该已经提供给你。如果没有，告诉用户运行 `/setup-dev-skills`。

## 流程

1. 如果尚未探索过代码库，先探索以了解当前状态。规格全文使用项目术语表中的词汇，并遵守涉及区域的 ADR。

2. 勾勒出你打算在哪些**接缝**（seams）上测试该功能。优先使用已有接缝，而非新建接缝。选择尽可能高层的接缝；若确需新接缝，也放在尽可能高的位置。贯穿代码库的接缝越少越好，理想数量是 1 个。

与用户确认这些测试接缝是否符合预期。

3. 使用下方模板编写规格，然后发布到项目的 issue 追踪器。附上 `ready-for-agent` 分诊标签，无需额外的分诊。

<spec-template>

## 问题陈述

从用户的视角描述用户面临的问题。

## 解决方案

从用户的视角描述解决方案。

## 用户故事

一份很长且带编号的用户故事列表。每条用户故事的格式如下：

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

<user-story-example>
1. 作为手机银行用户，我想查看各账户余额，以便在消费时做出更明智的决定
</user-story-example>

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

## 实现决策

已经确定的实现决策列表。可以包括：

- 要新建或修改的模块
- 这些模块中要修改的接口
- 开发者给出的技术澄清
- 架构决策
- schema 变更
- API 契约
- 具体交互

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

例外：如果原型产出的片段（状态机、reducer、schema、类型结构）比文字更准确地表达了决策，可以将其内联到相关决策中，并简要注明来自原型。只截取体现关键决策的部分，不要放完整的演示代码。

## 测试决策

已经确定的测试决策列表。包括：

- 什么是好的测试（只测试外部行为，不测试实现细节）
- 将要测试哪些模块
- 测试的先验参考（即代码库中类似的已有测试）

## 不在范围内

描述本规格明确不包含的内容。

## 补充说明

关于该功能的其他补充说明。

</spec-template>