toRolex 本 skill 结合当前对话上下文与对代码库的理解，产出一份 spec。不要访谈用户；只综合你已经知道的信息。
issue tracker 和 triage label 的词汇应该已经提供给你了。如果没有，让用户运行 /setup-rolex-skills。
流程
如果你还没探索过仓库，先探索一遍，理解代码库的当前状态。在整个 spec 中使用项目的 domain glossary 词汇，并尊重你所触及区域内的任何 ADR。
勾勒出你准备测试该功能的 seam。优先使用已有的 seam，而不是新建 seam。尽可能使用最高层级的 seam。如果需要新建 seam，尽量在你能做到的最高点提出。整个代码库中的 seam 越少越好——理想数量是一个。
与用户确认这些 seam 符合他们的预期。
使用下面的模板编写 spec，然后发布到项目的 issue tracker。应用
ready-for-agenttriage label——无需额外的 triage。
Problem Statement
用户所面临的问题，从用户的角度出发。
Solution
问题的解决方案，从用户的角度出发。
User Stories
一份非常长的、带编号的 user stories 列表。每条 user story 都应符合以下格式：
- 作为 <角色>，我想 <功能>，以便 <收益>
这份 user stories 列表应当极其详尽，覆盖该功能的方方面面。
Implementation Decisions
已做出的实现决策列表。可以包括：
- 将要构建/修改的 modules
- 这些 modules 将要修改的 interfaces
- 来自开发者的技术澄清
- 架构决策
- Schema 变更
- API contracts
- 具体的交互
不要包含具体的文件路径或代码片段，它们可能很快就会过时。
例外：如果 prototype 产出了一个比文字更能精确表达某个决策的片段（state machine、reducer、schema、type shape），把它内联到相关决策中，并简要注明它来自 prototype。只保留决策密集的部分，不是可运行的 demo，只是其中重要的片段。
Testing Decisions
已做出的测试决策列表。包括：
- 什么构成一个好的测试的描述（只测试外部行为，不测试实现细节）
- 将要测试哪些 modules
- 这些测试的先例（即代码库中相似类型的测试）
Out of Scope
本 spec 范围之外的内容描述。
Further Notes
关于该功能的任何进一步备注。