本技能会拿当前的对话上下文与对代码库的理解，产出一份规格说明。不要访谈用户；只综合你已经掌握的内容。
议题跟踪器与分诊标签词表应该已经提供给你了。如果没有，请告诉用户运行 /setup-matt-pocock-skills。
流程
-
探索仓库，弄清代码库的当前状态（如果你还没探索过）。整份规格说明都要使用项目领域词汇表的用词，并遵守你所触碰领域的任何 ADR。
-
勾画出你打算用来测试这个功能的接缝。已有接缝应优先于新建接缝。尽量使用最靠上的接缝。如果需要新接缝，就把它放在你能放的最高位置。整个代码库里的接缝越少越好——最理想的数量是一个。
与用户确认这些接缝符合他们的预期。
- 用下面的模板写规格说明，然后把它发布到项目的议题跟踪器。打上
ready-for-agent分诊标签——不需要再做额外的分诊。
问题陈述
用户正在面对的问题，从用户的视角来描述。
解决方案
问题的解决方案，从用户的视角来描述。
用户故事
一份很长、带编号的用户故事清单。每条用户故事都应采用下面的格式：
- 作为<某个角色>，我想要<某个功能>，以便<获得某种好处>
这份用户故事清单应当极其详尽，覆盖该功能的方方面面。
实现决策
已做出的实现决策清单。可以包括：
- 将要构建／修改的模块
- 这些模块中将被修改的接口
- 来自开发者的技术澄清
- 架构决策
- 数据结构变更
- API 契约
- 具体的交互
不要写出具体的文件路径或代码片段。它们可能很快就会过时。
例外：如果某个原型产出的片段比文字叙述更精确地表达了某项决策（状态机、归约器、数据结构、类型形状），就把它内联在相关决策里，并简短说明它来自原型。只保留决策密集的部分，不要整个可运行的演示，只要重要的那几点。
测试决策
已做出的测试决策清单。包括：
- 说明什么样的测试才算好测试（只测外部行为，不测实现细节）
- 哪些模块会被测试
- 测试的先例（即代码库中类似类型的测试）
不在范围内
描述本规格说明不涵盖的内容。
补充说明
关于该功能的任何其他说明。
