to-spec

name	to-spec
description	把当前对话变成一份规格（spec），并将其发布到项目的 issue tracker——不做访谈，只对你们已经讨论过的内容进行综合。
disable-model-invocation	true

这个技能获取当前对话上下文以及对代码库的理解，产出一份规格（你可能把这类文档称为 PRD）。不要访谈用户——只综合你已经知道的东西。

issue tracker 与分诊（triage）标签词汇应当已经提供给你——如果没有，运行 /setup-matt-pocock-skills。

流程

1. 探索仓库以理解代码库当前的状态（如果你还没这么做）。在整份规格中使用项目的领域词汇表词汇，并尊重你所触及区域内的任何 ADR。

2. 勾画出你打算在其上测试该功能的接缝（seam）。应优先选用现有接缝而非新接缝。使用尽可能高的接缝。如果需要新接缝，就在你能达到的最高点提出。代码库中接缝越少越好——理想数量是一个。

与用户核对这些接缝是否符合他们的预期。

3. 用下面的模板编写规格，然后把它发布到项目的 issue tracker。打上 ready-for-agent 分诊标签——无需额外分诊。同时打上一个 spec 标签，以便与普通工单区分开来。

问题陈述（Problem Statement）

用户正面临的问题，从用户的视角出发。

解决方案（Solution）

针对该问题的解决方案，从用户的视角出发。

用户故事（User Stories）

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

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

1. 作为一名手机银行客户，我想要看到我各账户的余额，以便就我的支出做出更明智的决策

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

实现决策（Implementation Decisions）

一份已做出的实现决策列表。可以包括：

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

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

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

测试决策（Testing Decisions）

一份已做出的测试决策列表。包括：

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

范围之外（Out of Scope）

对本规格范围之外的事项的描述。

补充说明（Further Notes）

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