to-spec

本技能基于当前对话上下文和对代码库的理解生成规格说明。不要采访用户，只综合你已掌握的信息。

问题追踪器和分诊标签词表应已提供给你。如果没有，请告知用户运行 /setup-matt-pocock-skills。

流程

1. 如果尚未探索，请先梳理代码仓库，了解代码库的当前状态。在整份规格说明中使用项目领域术语表中的词汇，并遵守你所修改区域内的 ADR。

2. 勾勒出你将用于测试该功能的接缝。应优先使用现有接缝，而非新建接缝。尽量使用层级最高的接缝。如果确需新接缝，请在你能达到的最高层级提出。整个代码库中的接缝越少越好，理想数量是一个。

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

3. 使用下方模板编写规格说明，然后发布到项目问题追踪器。应用 ready-for-agent 分诊标签，无需额外分诊。

问题陈述

用户从自身视角出发所面临的问题。

解决方案

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

用户故事

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

1. 作为 ，我希望 ，以便

1. 作为移动银行客户，我希望查看账户余额，以便更好地掌握消费情况，做出更明智的决策

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

实现决策

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

• 将要构建或修改的模块
• 这些将被修改的模块的接口
• 开发者提供的技术说明
• 架构决策
• Schema 变更
• API 契约
• 具体交互方式

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

例外情况：如果原型生成的代码片段比文字更精确地表达了某项决策（状态机、reducer、schema、类型结构），请将其内联到相关决策中，并简要说明其来自原型。只保留决策相关的关键部分，而非完整的可运行演示，只保留重要的内容。

测试决策

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

• 对何为好测试的描述（只测试外部行为，不测试实现细节）
• 将要测试的模块
• 测试的现有参考（即代码库中类似类型的测试）

范围之外

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

补充说明

关于该功能的任何其他说明。