Parallel Debugging 是一个用于调试复杂问题的技能框架，采用“竞争性假设分析”（Analysis of Competing Hypotheses，ACH）方法，结合并行代理调查来定位缺陷根因。
用途
该技能适用于以下场景：缺陷存在多个可能的根因；初步调试尝试未能识别问题；问题跨越多个模块或组件；需要带证据的系统性根因分析；希望在调试中避免确认偏差。
主要能力
假设生成框架
围绕 6 类失效模式生成假设：
- 逻辑错误：条件逻辑错误（运算符错误、遗漏分支）、循环或数组访问的差一错误、缺少边界情况处理、算法实现错误。
- 数据问题：无效或意外输入数据、类型不匹配或强制转换错误、期望有值处出现 null/undefined/None、编码或序列化问题、数据截断或溢出。
- 状态问题：并发操作间的竞态条件、缓存陈旧返回过期数据、初始化或默认值错误、共享状态被意外修改、状态机转换错误。
- 集成失败：API 契约违反（请求/响应不匹配）、组件间版本不兼容、环境间配置不匹配、环境变量缺失或错误、网络超时或连接失败。
- 资源问题：内存泄漏导致逐渐退化、连接池耗尽、文件描述符或句柄泄漏、磁盘空间或配额超限、低效处理导致 CPU 饱和。
- 环境问题：缺少运行时依赖、库或框架版本错误、平台特定行为差异、权限或访问控制问题、时区或区域相关行为。
证据收集标准
证据类型与强度：直接证据（强）、相关证据（中）、证词（弱）、缺失证据（可变）。
引用格式：始终以 file:line 引用证据，例如指出 src/validators/user.ts:87 处的验证函数未检查空字符串。
置信度分级：高（>80%）需多个直接证据、清晰因果链、无矛盾证据；中（50-80%）需部分直接证据、合理因果链、轻微歧义；低（<50%）多为相关证据、因果链不完整、存在矛盾证据。
结果仲裁协议
所有调查者报告后：
- 分类结果：已确认（高置信度、强证据、清晰因果链）、可能（中置信度、部分证据、合理因果链）、已证伪（证据与假设矛盾）、不确定（证据不足以确认或证伪）。
- 比较已确认假设：若多个假设被确认，按置信度、支持证据数量、因果链强度、无矛盾证据排序。
- 确定根因：若一个假设明显占优，宣布为根因；若多个假设同等可能，可能是复合问题；若无假设被确认，基于已收集证据生成新假设。
- 验证修复：修复针对已识别根因、不引入新问题、原始复现用例不再失败、相关边界情况已覆盖、相关测试已添加或更新。
运行时证据模式
当仲裁后假设仍为“可能”或“不确定”且静态证据已耗尽时，注入定向运行时日志以消除歧义。日志约定格式为：[DEBUG] [{file}:{line}] {short description} { {relevant vars} }。[DEBUG] 前缀不可省略，是清理锚点。
策略性放置：选择 3-5 个点，不要更多。位置包括函数入口（确认执行路径、参数）、异步调用前（操作前状态）、异步调用后（结果、错误、耗时）、条件分支（走了哪个分支）、catch 块（错误名称、消息、部分状态）。
不应记录的内容：密码、令牌、API 密钥（改用长度或存在/缺失标记）；PII（邮箱、电话、姓名）除非脱敏；完整请求/响应体（改用大小和选定字段）；热循环内部且无限流。
清理协议：缺陷验证修复后，移除所有 [DEBUG] 日志。以 grep 为准，若 grep 返回零匹配则清理完成。跨多行的 console 语句必须完整删除，删除后验证文件仍可解析。
迭代上限：一次调试会话最多进行 2 轮日志注入。若第二轮后假设仍不确定，向用户升级，附上已排除内容的书面摘要以及所需额外上下文（MCP 访问、生产日志、最小复现）。
专门调查代理
当假设落入上述 6 类失效模式之一时，优先使用专门调查者而非通用 team-debugger。对应关系：逻辑错误 → senior-review:code-auditor；数据问题 → senior-review:code-auditor 或 senior-review:security-auditor（数据跨越信任边界时用后者）；状态问题（并发、缓存、修改）→ UI 用 senior-review:ui-race-auditor，跨服务用 senior-review:distributed-flow-auditor；集成失败 → senior-review:distributed-flow-auditor；资源问题 → senior-review:code-auditor + react-development:react-performance-optimizer（前端时）；环境问题 → senior-review:chicken-egg-detector。当没有专门代理与假设干净匹配，或调查过于跨领域时，team-debugger 作为回退。
子代理生成注意事项：当 team-debugger 通过 Agent 工具生成专门子代理时，该子代理自身不能再生成子代理（Claude Agent SDK 限制：一级子代理嵌套）。若假设需要更深层委托，调试器应向团队负责人报告，而非间接链式调用。
输出持久化
team-debugger 代理和专门调查者都接受由生成方提供的输出文件路径。当编排器生成调查者并希望结构化报告落盘时，生成提示必须包含 Write your final report to <path>。调查者直接使用 Write 工具写入，而非仅作为消息文本返回报告。
使用方式
该技能以技能形式提供，具体安装命令、调用方式与集成步骤暂未提供。
适用场景
适用于复杂缺陷的根因分析、多模块问题排查、需要系统性证据收集与仲裁的调试任务，以及希望避免确认偏差的调试流程。
限制
日志注入最多 2 轮，超出需升级用户；子代理嵌套仅限一级；不应记录敏感信息；具体平台支持、收费与价格信息暂未提供。