GSD 自定义改造：当 Subagent Development 遇上进度追踪

背景

在用 GSD (Get Shit Done) 管理 manitodo 项目时，我发现了一个核心矛盾：我的实际工作流和 GSD 的预期工作流对不上。

GSD 预期的工作流： plan → execute (via /gsd:execute-phase) → create SUMMARY.md → update STATE.md 我的实际工作流： plan → subagent-driven development → git commit → (no SUMMARY.md)

这产生了两个具体问题：规划后自动路由至执行，和进度检测失效。

GSD 的工作原理

核心机制：文件即状态

GSD 不使用数据库或 API，所有状态都存在于文件中。进度计算方式：对比 PLAN.md 和 SUMMARY.md 的数量。没有 Summary = 未执行。

三种改造模式

1. 全量 Fork（重写逻辑）— 彻底改变 GSD 核心思维
2. Overlay + Adapter（模板源 + 平台适配）— 保留 GSD 主体，加适配层
3. Config + 自定义 Skill（轻量注入）— 只改几个路由行为

解决方案：两段式设计

1. 配置：设置 auto_advance: false 防止自动推荐执行
2. 后处理工具 gsd-advance：在做完 Subagent Development 后，为每个计划创建 Summary，调用 gsd-tools phase complete 更新状态

设计原则：轻量、可扩展、不触碰 GSD 源文件、可组合。

GSD 的进度系统本身是合理的，它的问题是假设执行必须通过 GSD Executor 完成。解决思路不是修改 GSD 的执行逻辑，而是在工作流的末端补齐状态同步环节。

2026-05-09