需要把需求落成可验证的实现规格（outcome…

在动手写代码前，为一项功能产出可执行、可验证的实现规格文档，并在范围过大时给出父子 spec 拆分方案。

适用场景

解决思路

1. 若提供了 $ARGUMENTS，就把它作为本次 spec 的主题。
2. 先调研代码库（使用 Explore agent），摸清现有实现与既有模式。
3. 通过 AskUserQuestion 访谈用户，确认关键技术决策、边界情况、测试方式与范围。
4. 对主题做文件名净化：去掉路径分隔符、特殊字符以及 `../` 等目录穿越模式。
5. spec 目录固定为 `.groove/memory/specs/`；若该目录不存在则先创建。
6. 评估范围：若工作存在天然接缝（相互独立的组件、前后顺序的阶段、可分离的关注点），建议拆分。
7. 拆分方案中，父 spec 写整个功能的概述、链接各子 spec，若是顺序执行还要给出执行顺序。
8. 拆分方案中，每个子 spec 自包含，各自拥有自己的 Overview、Decisions、Steps、Edge Cases。
9. 命名规则：单一 spec 用 `<topic>.md`；拆分后的 spec 用 `<topic>/index.md` 加 `<topic>/01-<part>.md`。
10. 把拆分建议连同理由呈现给用户，由用户确认或推翻（用户做最终决定）。
11. 在隔离上下文中撰写 spec（使用 general-purpose agent）。
12. spec 必须包含 **Overview**：要构建什么以及为什么。
13. spec 必须包含 **Decisions**：关键技术选型及其理由，且要引用真实的代码库模式，而不是通用建议。
14. spec 必须包含 **Implementation Steps**：具体、有序的步骤，写明实际的文件路径和函数名。
15. spec 必须包含 **Edge Cases**：错误处理与边界条件，且反映调研中发现的真实约束。
16. 完成前逐项校验所有必需章节是否都已存在。
17. 自查质量信号：Decisions 引用真实代码模式、Steps 含实际文件路径与函数名、Edge Cases 对应已发现的约束。

适用边界 · 注意事项

• 改动是一次性、极小的任务：写完整 outcome spec 的开销大于收益。
• 需求已完全明确、无需访谈用户也无需调研代码库的纯机械执行任务。
• 无法访问任何代码库（如全新绿地项目）时，"引用真实代码模式而非通用建议" 这一要求无法满足。