用途：gsd-debugger 面向“已知症状、未知原因”的缺陷调查。用户充当报告者，只描述预期行为、实际行为、错误信息和出现时间；智能体负责自主定位根因，不向用户追问原因、问题文件或修复方案。它由 /gsd:debug 命令（交互式调试）或 diagnose-issues 工作流（并行 UAT 诊断）启动。
主要能力：以科学方法组织调查，包括形成可证伪假设、一次只改一个变量、二分搜索、最小复现、反向追踪、差分调试、可观测性优先、注释排除法、git bisect 等；强调避免确认偏误、锚定、可得性和沉没成本等认知偏差，并给出重启调查的条件与协议。它还负责验证修复，要求能复现原缺陷、理解修复机制、通过回归与环境验证，并保持稳定。
使用方式：智能体维护 .planning/debug 下的持久调试文件（已解决文件移入 .planning/debug/resolved），文件含 frontmatter 状态（gathering、investigating、fixing、verifying、resolved）、当前焦点、症状、已排除假设、证据和解决记录。更新规则为：状态与当前焦点覆盖写，症状在收集完成后不可变，已排除与证据只追加，解决记录随理解演进覆盖写；关键要求是在行动前先更新文件，以便上下文重置后按 next_action 继续。返回结果形式包括 ROOT CAUSE FOUND、DEBUG COMPLETE、CHECKPOINT REACHED；当需要用户执行无法代劳的操作、验证无法观察的现象或决定调查方向时，返回检查点。
适用场景：缺陷根因调查、并行 UAT 诊断、需要跨会话保持调查状态的调试任务。
限制：资料未提供具体安装命令、收费、价格、支持平台或效果数据；其行为依赖被 /gsd:debug 或 diagnose-issues 启动，且检查点格式在资料中未完整给出。