用途：当面对多个彼此无关的失败（不同测试文件、不同子系统、不同缺陷）时，顺序排查会浪费时间。该技能的核心原则是按独立问题域各派发一个智能体，让它们并发工作。
适用场景：3个以上测试文件因不同根因失败；多个子系统各自独立损坏；每个问题无需其他问题的上下文即可理解；各排查之间没有共享状态。不适用：失败彼此相关（修一个可能连带修好其他）、需要了解整个系统状态、智能体之间会互相干扰的情况。
使用方式：
- 识别独立域：按“哪里坏了”对失败分组，每个域相互独立。
- 创建聚焦的智能体任务：给每个智能体指定具体范围（一个测试文件或子系统）、明确目标（让这些测试通过）、约束（不要改动其他代码）、期望输出（发现与修复的摘要）。
- 并行派发，例如在 Claude Code / AI 环境中执行： Task("Fix agent-tool-abort.test.ts failures") Task("Fix batch-completion-behavior.test.ts failures") Task("Fix tool-approval-race-conditions.test.ts failures") 三者会并发运行。
- 审阅与整合：阅读每份摘要、确认修复之间无冲突、运行完整测试套件、整合全部改动。
智能体提示词结构：应聚焦（一个清晰问题域）、自包含（包含理解问题所需的全部上下文）、对输出有明确要求（智能体应返回什么）。
常见错误：范围过宽（“修复所有测试”）会让智能体迷失，应具体到某个测试文件；缺少上下文（“修复竞态条件”）应附上错误信息和测试名；没有约束时智能体可能重构一切，应写明“不要改动生产代码”或“只修测试”；输出含糊（“修好了”）应改为“返回根因与改动摘要”。
验证：智能体返回后，逐份审阅摘要、检查是否编辑了同一代码、运行完整测试套件、人工抽查，因为智能体可能犯系统性错误。
资料中给出的真实示例：某次重构后 3 个文件共 6 个测试失败，分别派发 3 个智能体并行处理，最终所有修复独立、无冲突，整套测试通过。
限制：仅在失败相互独立且无共享状态时适用；不适用于失败相关、需全系统上下文或探索性调试的场景。收费、价格、平台支持等细节资料暂未提供。