GSD Debugger 是一个专注于系统化调试的代理技能，其核心目标是帮助开发者找到问题的根本原因，而不仅仅是让症状消失。它适用于需要深入调查 bug、定位回归问题或处理复杂系统故障的场景。
该技能的核心哲学是“用户是报告者，AI 是调查者”。用户通常知道预期行为、实际现象、错误信息以及问题开始的时间，但不知道问题的原因、涉及的文件或修复方法。因此，调试过程应聚焦于询问用户的体验，而由 AI 自主调查原因。
在调试自己编写的代码时，GSD Debugger 强调“元调试”的挑战：开发者容易陷入自己的心智模型，认为设计决策理所当然，记住的是意图而非实际实现，熟悉导致对 bug 的盲视。为此，它要求将代码视为他人所写，质疑设计决策，承认心智模型可能错误，并优先检查最近修改过的代码。
该技能建立在事实基础上，区分确定的事实与假设，避免确认偏误、锚定效应、可得性偏误和沉没成本等认知偏差。它提倡系统化调查：每次只改变一个变量，完整阅读函数而非仅看相关行，拥抱“我不知道”的状态，并在长时间无进展、多次修复失败、无法解释当前行为或修复有效但不知原因时考虑重启调查。
假设检验要求假设可证伪，例如“用户状态被重置是因为组件在路由变化时重新挂载”而非“状态有问题”。形成假设时需要精确观察、列出所有可能原因、使每个假设具体化，并确定支持或反驳每个假设的证据。
该技能提供了多种调试技术：橡胶鸭调试（通过向他人或自己解释来发现问题）、最小化复现（逐步移除代码直到最小可复现案例）、逆向工作（从期望输出反向追踪）、差分调试（比较工作与不工作状态之间的变化）、二分搜索（在大型代码库或长历史中定位问题）以及注释掉所有代码再逐段恢复。
验证环节定义了“已验证”的含义：可稳定复现、修复不破坏其他功能、在所有相关环境中有效、重试后 bug 不返回。验证清单包括修复前复现、应用修复、确认不再复现、相关功能正常、边缘情况测试以及原始报告者确认（如适用）。
3 次规则规定，在 3 次修复尝试失败后，应停止当前方法，将尝试记录到 DEBUG.md，总结到 STATE.md，并建议使用新上下文重新开始会话。DEBUG.md 文档结构包含状态、触发输入、时间戳、当前焦点（假设、测试方法、预期结果、下一步行动）、症状（预期、实际、错误）、已排除的假设及证据、证据记录以及解决方案（根本原因、修复、验证）。
输出格式包括“找到根本原因”（包含具体原因、证据和推荐修复）、“调查无结论”（列出已排除的假设、剩余的假设、阻塞因素和下一步建议）以及“检查点”（状态、进度和需要用户回答的问题）。
该技能未提供具体的安装命令、收费信息或平台限制，这些信息暂未提供。