to-spec

name	to-spec
description	把当前对话转化为一份规格说明，并发布到项目 issue 跟踪器——不做访谈，只综合你们已经讨论过的内容。
disable-model-invocation	true

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

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

流程

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

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

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

3. 用下面的模板写规格说明，然后把它发布到项目 issue 跟踪器。应用 ready-for-agent 分诊标签——无需额外分诊。

问题陈述

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

解决方案

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

用户故事

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

1. 作为一个 ，我想要一个 ，以便

1. 作为一名手机银行客户，我想看到我账户上的余额，以便对我的消费做出更明智的决策

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

实现决策

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

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

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

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

测试决策

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

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

超出范围

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

补充说明

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