用途
该技能用于把当前对话中已经讨论清楚的内容与对代码库的理解，整理成一份结构化规格说明，并发布到项目的问题跟踪器，供后续 /to-tickets、/tdd 等环节使用。
主要能力
- 默认综合已有对话与代码库理解来生成规格，不把已经做出的决定重新打开为访谈。
- 仅在存在无法通过对话、代码库、GLOSSARY.md 或 ADR 填补、且会迫使臆造用户未做决定的关键缺口时提问。
- 提问方式为一次性批量提出，附带最佳猜测，便于用户确认；只保留真正影响规格内容的少数问题。
- 测试接缝（seams）作为批量问题之一提出，或在没有其他问题时单独用一条简短问题确认。
- 自动解析发布目的地，不向用户弹出选择器。
- 按固定模板撰写规格，包含问题陈述、解决方案、用户故事、实现决策、测试决策、范围外内容和补充说明。
- 发布后应用 ready-for-agent 分诊标签；本地 markdown 则以 Status 行记录。
使用方式
- 解析发布目的地：优先使用用户本次明确指定的 GitHub、GitLab、本地 markdown 或其他跟踪器；否则若存在 docs/agents/issue-tracker.md 并命名了跟踪器则使用之；否则写入本地 .scratch/<feature-slug>/SPEC.md。不探测 git remote，不展示目的地选择器。
- 探索仓库以理解代码库现状，在规格中沿用项目领域术语，并遵守相关区域的 ADR。
- 草拟测试接缝，优先复用现有接缝，尽量取最高层，接缝数量越少越好，理想为一个。接缝不单独确认，而是放入上述批量问题中；确认后的接缝写入规格的 Testing Decisions。
- 按模板撰写规格并发布：GitHub 使用 gh issue create --title "..." --body "..."（多行正文用 heredoc），分诊标签用 --label；GitLab 使用 glab issue create --title "..." --description "..."（多行描述用 heredoc），分诊标签用 --label；本地 markdown 写入 .scratch/<feature-slug>/SPEC.md，必要时创建目录，并在文件顶部附近写 Status: ready-for-agent 行代替标签。
规格模板结构
- Problem Statement：从用户视角描述所面临的问题。
- Solution：从用户视角描述解决方案。
- User Stories：长篇编号列表，格式为“As an , I want a , so that ”，尽量覆盖功能各个方面。
- Implementation Decisions：列出已做出的实现决策，可包括将构建/修改的模块、模块接口变更、开发者的技术澄清、架构决策、模式变更、API 契约、具体交互。不包含具体文件路径或代码片段；例外是原型中能比文字更精确表达决策的片段（状态机、reducer、模式、类型形状），可内联并注明来自原型，只保留决策密集部分。
- Testing Decisions：列出测试决策，包括何为良好测试（只测外部行为，不测实现细节）、逐条列出的已确认接缝（便于 /to-tickets 和 /tdd 使用）、将测试的模块、测试的现有先例。
- Out of Scope：说明本规格范围外的事项。
- Further Notes：关于该功能的进一步说明。
适用场景
适用于对话中已经完成决策、需要将讨论固化为可执行规格并进入问题跟踪器的开发流程；尤其适合需要后续拆票与测试驱动开发的团队。
限制
- 资料未说明该技能支持的具体平台范围、收费方式或效果保证。
- 发布目的地解析顺序固定，未提供交互式选择目的地的能力。
- 提问有严格门槛，不会为了补全而逐条访谈。
- 规格模板中不建议包含具体文件路径或代码片段（原型决策片段除外），因此规格不含实现级路径细节。