Debug Tools 是一套迭代式调试工作流，主打以证据为导向，用于处理意外、静默或间歇性的失败。它的定位不是通用的缺陷修复工具，而是面向需要系统化排查的调试场景。
主要能力方面，该工具通过调查、修复、验证、完成的循环推进调试过程，并在流程中提供灵活的技术选择与升级机制。工作流最多尝试 3 次，之后升级处理。它包含若干按需加载的模块：investigation.md 用于理解缺陷、分析代码、枚举带置信度评分的假设、排序、提出修复、验证并报告；debugging-patterns.md 用于将症状与已知缺陷形态匹配，或在分析停滞、需要将出错代码与可工作示例对比时使用，也适用于用户报告“以前能用”的情况；log-injection.md 在阅读代码无法揭示机制、只能观察运行系统时加载；log-cleanup.md 在修复验证后或明确请求时加载，并需在变更进入版本控制前运行。
使用方式上，该工具定义了几类触发入口：调试缺陷（如“debug this”“investigate”“trace issue”“fix bug”“why is X broken”）会运行完整工作流；添加调试日志（如“add debug logs”“inject logs”“trace with logs”）从第 3 步进入；清理日志（如“remove debug logs”“cleanup logs”）从第 5 步进入；模式查询（如“debug patterns”“common bugs”“used to work”）从第 2 步进入。会话可根据当前状态直接进入对应步骤，已携带证据的会话不必从第 1 步重启。工具强调只在证据指明机制时才提出修复，绝不作为探索性尝试；修复应用后需运行复现，对竞态条件或间歇性缺陷需重复 3-5 次。安全性上，注入日志绝不包含密码、令牌、API 密钥、PII、会话标识等敏感值，且该约束适用于任何添加日志的场合，包括未加载第 3 步的排查中途。
适用场景包括：追踪难以复现的缺陷、为调试注入针对性日志、验证修复效果、清理调试日志、匹配常见缺陷模式。限制方面，该工具不适用于已知问题的处理；资料未提供其收费、价格、平台、具体效果或安装方式等信息。其明确反对的反模式是“症状打地鼠”：在同一症状的多处反复修复意味着架构问题而非局部缺陷，当修复 N 引发缺陷 N+1 时应停止，第 4 次尝试必须升级为架构审查，重新检查抽象、缺失层或有缺陷的假设，而不是重复更深层的同一方案。