当前分支提交审查：用三级分类把盲点变成立即修复…

在处理完一轮开发后，审查当前分支相对 main 的改动（或聚焦某个主题），找出盲点并就近落地为行动。

适用场景

解决思路

1. 确定审查范围：不带参数时审查当前分支与 main 的差异；带 topic 参数时只聚焦该领域。
2. 若提供了 topic，先对其做安全清理：去掉路径分隔符、特殊字符以及路径穿越模式（如 `../`）。
3. 收集上下文：获取分支 diff，并读取相关 spec；spec 目录固定为 `.groove/memory/specs/`。
4. 在隔离的上下文中运行分析（使用 general-purpose agent）。
5. 如果子代理（subagent）执行失败，回退为直接审查。
6. 把发现的问题按后续动作分类：Fix Now（工作量极小，立即修）、Needs Spec（重要，但需要先规划）、Create Issues（工作量大或属于 nice-to-have）。
7. 呈现发现时标注严重程度和工作量估算。
8. 执行选定的动作：直接修复、通过 `/groove-work-spec <topic>` 创建 spec，或创建 issue。

适用边界 · 注意事项

• 仓库没有可对比的分支/提交（例如直接在 main 上、或没有 git 历史）时无法产出 diff。
• 未对 topic 做清理时不要把它用于路径拼接，避免路径穿越。
• 需要跨仓库、跨团队的大范围架构决策时，此流程只做分支级审查，不足以覆盖。