测试意外失败
先完整阅读失败信息，与相近正常案例比较，再修改代码。
Systematic Debugging by Jesse Vincent
使用 Superpowers 的 Systematic Debugging，在提出修复前先调查故障。复现行为，比较正常与异常路径，检验具体解释，再验证针对根因的修改，避免在未解决的问题上不断叠加推测性改动。
安装与快速上手
选择你使用的 Agent，查看对应的安装或使用方式。在 Floatboat 中，可复制请求让 Agent 读取原始说明；其他选项会显示该 Skill 的安装命令或发布者提供的原生步骤。
选择 Agent
在 Floatboat 中开始
复制请求，粘贴到 Floatboat 对话
请阅读 https://github.com/obra/superpowers/blob/main/skills/systematic-debugging/SKILL.md 中的 Systematic Debugging 原始说明，介绍它的用途、所需工具和安装方式，再协助我使用。由 Agent 读取原始说明，再确认当前环境的使用方式。
下载 Floatboat ↗试试这样提问
使用 Superpowers Systematic Debugging 调查仅 CI 出现的构建失败，先比较流水线环境传递，再提出修复并验证原始任务。
关于 Systematic Debugging
Systematic Debugging 是 Superpowers 的根因调查 Skill，由 Jesse Vincent 及项目贡献者维护。它将工作分为证据收集、模式比较、假设检验和实施四个阶段，要求 Agent 先读错误、复现失败、检查近期变化，并观察组件边界上的数据，再选择修复。每次通过小测试检验一个解释；实施阶段需要失败复现与结果验证。连续多次修复无效时，应转向架构讨论，而不是继续盲改。完整流程引用配套测试与完成验证 Skills，实际使用仍依赖访问故障发生环境及必要的诊断工具。
系统化调试的使用场景
探索可见症状尚不能说明原因的故障。可以诊断失败测试、跨组件追踪构建或集成错误，或重新调查多次修复无效的问题；以证据约束修改，让每个动作对应一个可检验的原因解释。
流水线在组件之间失败
核对每个边界的输入和输出，确定实际失败层。
多次尝试修复无效
重新检查假设并讨论架构原因，而不是再叠加未检验补丁。
如何按根因调查故障
提供准确错误、预期行为与复现环境，先收集证据并比较正常模式。用最小改动检验一个假设，再实施有证据支持的修复，并参考配套验证方法确认原始症状及相关测试均已解决。
- 01
收集证据与正常模式
复现错误、检查近期变化并比较正常路径，多组件问题可添加针对性边界观察。
- 02
检验一个解释
提出具体假设并进行最小有效测试，每次改变一个变量，评估后再选择其他解释。
- 03
实施并验证根因修复
保留失败复现、实施有依据的修复并重跑相关检查，连续失败时转入设计讨论。
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
Systematic Debugging 常见问题
它与 Matt Pocock 的 Diagnosing Bugs 有何不同？
它们属于不同发布者的独立流程。Superpowers 使用四阶段及配套测试与验证，Matt 当前流程尤其强调可失败的紧密反馈循环和最小复现。
可以立刻应用看起来明显的修复吗？
该 Skill 要求先调查根因。看似合理的改动不等于证据，应说明它为何解决观察到的故障并验证行为。
四个阶段是什么？
分别是根因调查、模式分析、假设检验和实施，各阶段为下一阶段提供证据。
连续几次修复失败后应怎样？
原文要求三次及以上修复无效后停下来审视架构，不再继续增加推测补丁。
引用了哪些配套 Skills？
实施阶段引用 test-driven-development 编写失败测试，以及 verification-before-completion 检查最终结果，应通过 Superpowers 集成保留它们。
测试通过就一定修复了吗？
需要确认测试确实复现用户症状，并在修复后重跑原始流程。相近条件通过可能遗漏根本故障。
无法访问故障环境时能诊断吗？
它可以组织调查，但缺少复现证据会限制结论。应提供适当脱敏日志或代表环境，并将未证实解释保留为假设。
Codex App 与 Codex CLI 如何分别安装？
Codex App 在侧栏 Plugins 中找到 Coding 下的 Superpowers，点击 + 并按提示安装；Codex CLI 运行 /plugins，搜索 Superpowers 并选择 Install Plugin。两者是官方插件市场的不同界面入口。