debugging-and-error-recovery
作者 addyosmanidebugging-and-error-recovery 技能用于指导系统化的根因调试，适用于测试失败、构建中断、运行时错误和回归问题。它强调先保留证据、稳定复现问题、按顺序诊断、以最小改动修复，并在继续之前完成验证。
该技能评分为 78/100，说明它是目录用户值得考虑的稳健条目。它提供了清晰的触发场景、较完整的分步调试流程，以及足够的操作细节，能让代理在执行时比通用提示少一些猜测；不过用户也应预期，这仍是一个以文本说明为主、生态支持有限的技能。
- 对测试、构建、运行时 Bug、日志和异常错误给出了清晰且高信号的触发条件。
- 操作指引扎实，包含 stop-the-line 规则和结构化分诊清单，有助于提升代理执行质量。
- 正文内容较充实，包含多个标题和具体恢复步骤，说明它不只是一个占位型技能。
- 没有脚本、参考资料或支持文件，用户需要主要依赖 markdown 指南本身。
- 带有实验性/测试性质标记，且未提供 install 命令，可能会降低需要打包式上手体验的团队信心。
debugging-and-error-recovery 技能概览
debugging-and-error-recovery 技能是一套结构化的故障诊断方法，重点是不靠猜测来定位失败。它特别适合正在面对失败测试、构建中断、运行时行为异常、噪声日志，或只在修改之后才出现回归问题的开发者和 agent。如果你需要用于 Debugging 的 debugging-and-error-recovery 技能，目标不只是“修一个错误”，而是先保留证据、复现问题、找出根因，再继续做其他改动。
这个技能适用于什么场景
当故障真实存在、但原因不清楚时，这个技能最有价值。它强调“先停下来”的思路：不要在已知问题未解决时继续推进新功能。这使它非常适合测试驱动流程、事故分流，以及任何一个小失误都可能引发连锁误报的仓库。
谁应该安装它
如果你经常和 agent 一起调试代码，并且希望有一套可重复的流程，而不是临时起意的提示词，那么就应该安装 debugging-and-error-recovery。它尤其适合希望把日志、失败的 CI 和 bug 报告更高质量地交接成修复计划的团队。
它为什么不一样
它的核心价值是纪律性：先复现，再保留证据，按顺序诊断，然后验证修复并防止复发。这比泛泛的“帮我调试一下”提示词更适合直接做决策，因为它明确告诉 agent 在第一次尝试失败后该如何行动。
如何使用 debugging-and-error-recovery 技能
安装并加载该技能
先通过 repo manager 按 debugging-and-error-recovery 的安装流程安装，然后第一步阅读 SKILL.md。这个仓库里没有辅助脚本或配套目录，所以这个技能故意做得很轻量，重点放在一套清晰流程上，而不是一整套工具链。
把模糊的 bug 变成可用的提示词
debugging-and-error-recovery 的用法在你一开始就提供三类信息时效果最好：症状、证据和边界。例如，不要只说“帮我修一下 app”，而要说：“npm test 在提交 abc123 之后在 user-auth.spec.ts 失败；这里是堆栈信息、期望行为和上一次已知正常的运行结果。” 这样技能就有足够上下文去复现和分流，而不是凭空编造理论。
适合获得最佳结果的推荐流程
先要求 agent 在改代码之前保留证据并复现问题。然后让它按顺序走分流步骤：复现、隔离、检查最近改动、定位根因、最小化修复、再验证。这个流程很重要，因为该技能是为 debugging-and-error-recovery 优化的，不是为功能扩展或大范围重构设计的。
先阅读这些仓库文件
对于这个仓库，首先要读的是 SKILL.md。这里没有额外的参考文档、规则或脚本可查，这让接入更简单，但也意味着你需要在提示词里补充自己的项目约束、命令和环境信息。
debugging-and-error-recovery 技能 FAQ
它比普通调试提示词更好吗？
通常是的，前提是你想要一致性。普通提示词可以要求修复问题，但 debugging-and-error-recovery 额外加入了一套流程：先停下、保留证据、复现、按顺序诊断、再验证。这能减少那种“快速修一下”却把真正问题藏起来的行为。
什么时候不该用它？
当你在做推测性的架构工作、功能规划，或者根本没有可观察到的故障时，不要用它。如果你是在探索设计方案，而不是从错误中恢复，那么 debugging-and-error-recovery 这份指南可能过于受限，不适合这类任务。
它适合新手吗？
适合，因为流程是明确的。新手会从“要收集什么、先查什么”这类指引中受益。主要限制是，新手仍然需要提供真实症状，而不是只给一个笼统的求助请求。
它适合典型的 agent 工作流吗？
适合。当 agent 能访问日志、测试、diff 和可运行环境时，它的效果最好。如果 agent 不能检查证据或验证修改，它就不太有用，因为恢复闭环依赖反馈。
如何改进 debugging-and-error-recovery 技能
提供更强的故障输入
想让 debugging-and-error-recovery 的输出更好，最有效的方法是提供精确的失败形式、触发它的命令、期望结果、实际结果以及最近的变更。例如：“pnpm test 在 Linux 上升级 zod 后才失败；这里是 diff 和堆栈信息。” 这样能立刻缩小搜索范围。
保留技能可以直接利用的上下文
把日志、截图、复现步骤、环境信息，以及任何已知正常基线都提供出来。这个技能在能比较“改动前”和“改动后”时表现更好，而不是从一段空白描述开始。如果 bug 是间歇性的，也要明确说明，并解释是什么让它更容易出现。
要求最小修复和验证
一个高质量的 debugging-and-error-recovery 使用提示词，应该要求最小且安全的修复，并附带验证方案或测试更新。这有助于避免矫枉过正，也让输出更符合重视稳定性的团队安装使用。
第一次尝试后继续迭代
如果第一轮结论不明确，就用下一批最有价值的证据来细化提示词：更窄的复现步骤、更具体的堆栈信息，或者更可疑的准确文件路径。debugging-and-error-recovery 技能最能发挥作用的时候，是每次迭代都在消除不确定性，而不是重复陈述同一个症状。