用途
to-spec 用于把当前对话中已经积累的上下文，连同对代码库的了解，直接转化一份项目规格说明（spec）。它的定位是“合成”而非“访谈”：不向用户逐项提问，而是把已知信息整理成结构化文档。
主要能力
- 探索代码库：生成规格前先查看仓库，了解代码当前状态。
- 统一术语：整份规格使用项目术语表（glossary）中的词汇（统一语言），并遵循所触及区域的 ADR（架构决策记录）。
- 梳理测试接缝：构想测试该功能所用的测试接缝（seams），原则是优先复用已有接缝而非新建、尽量使用最高层级的接缝、新建时也放在尽可能高的位置，接缝数量越少越好（理想为一个）；接缝方案需与用户确认是否符合预期。
- 按模板撰写规格：包含问题陈述（从用户视角描述问题）、解决方案（从用户视角描述解法）、用户故事（冗长且编号的列表，格式为“作为<角色>，我想要<功能>，以便<收益>”，需覆盖功能的所有方面）、实现决策（将构建或修改的模块、这些模块将变更的接口、开发者的技术澄清、架构决策、数据库模式变更、API 契约、具体交互等；不包含文件路径与代码片段，例外是原型中能更精确表达决策的片段，如状态机、reducer、schema、类型形状，可放入对应决策并注明来自原型，且只保留决策要点而非完整演示）、测试决策（何为好的测试——只测外部行为而非实现细节、哪些模块会被测试、代码库中已有的同类测试作为先例）、范围之外、补充说明。
- 保存与发布：将规格保存到 docs/specs/<YYYY-MM-DD>-<slug>.md；若项目没有 docs/，则存至 .hermes/plans/。如用户要求，也可发布为 GitHub issue，打上 ready-for-agent 标签，无需额外分诊。
- 自检：核对规格是否使用项目领域词汇而未自造同义词、用户故事是否覆盖功能全部方面、实现决策是否不含文件路径与代码片段（原型例外除外）、测试接缝是否已与用户确认、规格是否已保存到项目中。
使用方式
在已有对话上下文的场景下调用该技能，它会先探索仓库，再提出测试接缝并与用户确认，随后按模板生成规格并保存。是否发布为 GitHub issue 由用户决定。
适用场景
适合在对话中已讨论清楚某项功能或改动、需要沉淀为可执行的规格文档时使用；也适合希望规格与项目术语、ADR 保持一致，并同时明确测试策略的团队工作流。
限制
该技能不通过访谈补全缺失信息，而是综合已有认知，因此对话上下文和代码库信息不足时，生成的规格可能不完整。模板中明确不记录文件路径和代码片段（除原型决策例外）；它本身不描述具体收费、价格或平台支持情况，这些信息暂未提供。