unity-to-spec

这项技能会利用当前对话上下文和对代码库的理解来编写规格说明。不要采访用户；只需综合已有信息。

流程

1. 如果你还没有了解代码库的当前状态，请先探索仓库。通篇使用项目领域术语表中的词汇，并遵循你所涉及领域的任何 ADR。

2. 勾勒出用于测试此功能的测试边界。优先使用现有边界，并尽可能选择最高层级的边界。如果需要新增边界，应尽可能在最高层级提出。跨越代码库的边界越少越好，理想数量为一个。

向用户确认这些测试边界是否符合他们的预期。

3. 使用以下模板，将规格说明写入 docs/<feature-slug>/spec.md：

问题陈述

从用户的角度描述他们遇到的问题。

解决方案

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

用户故事

一份内容详尽、带编号的用户故事列表。每条用户故事应采用以下格式：

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

1. 作为一名关卡设计师，我希望在 Unity 场景中放置并配置检查点预制件，以便无需更改代码即可调整玩家的重生位置。

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

实现决策

列出已作出的实现决策，包括：

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

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

例外：如果原型生成的代码片段比文字更准确地表达了某项决策（例如状态机、reducer、Schema 或类型结构），可将其内嵌在相关决策中，并简要说明该片段来自原型。只保留体现决策的关键部分，不要保留可运行的演示代码，只需呈现重要内容。

测试决策

列出已作出的测试决策，包括：

• 优质测试的特征（只测试外部行为，不测试实现细节）
• 将测试的模块
• 测试的先例（即代码库中类似的测试）

范围之外

描述本规格说明不涵盖的事项。

补充说明

关于此功能的其他补充说明。