to-spec

name	to-spec
description	将当前对话转化为规范（spec）并发布到项目 Issue 跟踪器——无需采访，仅综合已经讨论过的内容。
disable-model-invocation	true

本技能获取当前对话上下文和代码库理解，生成一份规范（你可能将此文档称为 PRD）。不要采访用户——只综合你已知的内容。

Issue 跟踪器和分类标签词汇表应已提供给你——如果没有，请运行 /setup-matt-pocock-skills。

流程

1. 探索仓库以了解代码库当前状态（如果尚未探索）。在整个规范中使用项目的领域术语表词汇，并尊重你正在接触的区域的 ADR。

2. 勾勒你将要测试该功能的 seams。应优先使用现有的 seams 而非新建。使用尽可能高的 seam。如果需要新的 seam，在你能达到的最高点提出它们。代码库中的 seam 越少越好——理想数量是一个。

与用户确认这些 seams 是否符合他们的期望。

3. 使用下面的模板编写规范，然后发布到项目 Issue 跟踪器。应用 ready-for-agent 分类标签——无需额外分类。

问题陈述

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

解决方案

问题的解决方案，从用户的角度出发。

用户故事

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

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

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

用户故事列表应非常详尽，覆盖功能的所有方面。

实现决策

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

• 将要构建/修改的模块
• 这些模块将要被修改的接口
• 开发者的技术说明
• 架构决策
• Schema 变更
• API 契约
• 特定交互

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

例外：如果原型产出的代码片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型结构），将其内联在相关决策中，并简要说明来自原型。精简到决策密集的部分——不是工作演示，只是重要的内容。

测试决策

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

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

范围外

此规范范围外的内容描述。

进一步说明

关于该功能的任何进一步说明。