to-spec

此技能会根据当前对话上下文和对代码库的理解编写规格说明。默认综合已有信息：运行此技能时，通常已经做出了决定，因此不要重新以访谈的方式讨论。

确有需要时，你可以提问。 只有当存在无法通过对话、代码库、GLOSSARY.md 或 ADR 弥补的空缺，而且不提问就会迫使你擅自替用户做决定时，才应提问。遇到这种情况时：

• 在编写规格说明前一次性提出所有问题，不要逐个提问。
• 只问那些确实会影响规格说明内容的问题。
• 每个问题都附上你的最佳猜测，方便用户确认。
• 接缝（第 3 步）是其中一个问题：在这一批问题中附上你建议的接缝作为最佳猜测。如果其他问题都不符合提问条件，就只简短询问接缝。
• 然后编写规格说明。不要因为等待答复而停滞；可以假设并标注那些你能够自行处理的事项。

如果没有任何问题符合提问条件，就直接编写规格说明，但接缝除外：必须在问题批次中确认接缝，或者单独简短询问接缝。

流程

1. 确定发布位置。 这一步绝不需要提问：按以下顺序总能找到目标位置，因此请自行选择，并在第 4 步沿用，不要让用户选择。

   1. 如果用户明确要求本次发布到 GitHub、GitLab、本地 Markdown 或其他跟踪系统：使用该目标。
   2. 否则，如果 docs/agents/issue-tracker.md 存在（由 /setup-skills 编写）且指定了跟踪系统：使用该系统。
   3. 否则：使用本地 Markdown（.scratch/<feature-slug>/SPEC.md）。不要探测 git remote。不要让用户选择发布位置。

   如果使用 GitHub 或 GitLab，且 docs/agents/issue-tracker.md 存在，请遵循其中的规范和分类标签映射；否则请遵循下方的 <destination-conventions>。运行 /setup-skills 配置这些规范和分类标签词汇。

2. 如果你尚未了解代码库的当前状态，请先探索仓库。整个规格说明中应使用项目的领域术语，并遵守相关 ADR。

3. 规划要测试此功能的接缝。优先使用已有接缝，并选择尽可能高层的接缝。如需新增接缝，请在尽可能高的层级提出。跨代码库的接缝越少越好——理想情况下只有一个。

   不要单独确认接缝：按照上述批量提问的方式一并询问用户，并将达成一致的接缝写入规格说明的「测试决策」部分。

4. 使用下方模板编写规格说明，然后发布到第 1 步确定的目标位置。应用 ready-for-agent 分类标签：无需额外分类。对于本地 Markdown，所谓“应用标签”是指在文件靠近顶部的位置写入 Status: ready-for-agent。

• GitHub：使用 gh issue create --title "..." --body "..."（多行正文使用 heredoc）。通过 --label 设置分类标签。
• GitLab：使用 glab issue create --title "..." --description "..."（多行说明使用 heredoc）。通过 --label 设置分类标签。
• 本地 Markdown：写入 .scratch/<feature-slug>/SPEC.md，必要时创建目录。不要设置标签，而是在文件靠近顶部的位置记录分类状态 Status:。

问题陈述

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

解决方案

从用户的角度描述解决该问题的方案。

## 用户故事

一份很长的编号用户故事列表。每条用户故事的格式应为：

1. 作为一名 ，我希望拥有一项 ，以便

1. 作为一名手机银行客户，我希望查看账户余额，以便更好地了解自己的支出并做出明智的决定

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

实现决策

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

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

请勿包含具体文件路径或代码片段。这些内容可能很快就会过时。

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

测试决策

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

• 优质测试的标准说明（只测试外部行为，不测试实现细节）
• 已商定的测试接缝，每条单独列出，以便 /to-tickets 和 /tdd 使用
• 将要测试的模块
• 测试的先例（即代码库中类似类型的测试）

不在范围内

说明本规范不涉及的事项。

补充说明

有关该功能的其他说明。