Bug Hunt Swarm 是一项并行、只读的多智能体根因调查技能，用于排查 bug、回归、崩溃、偶发行为或无法解释的失败。它采取诊断优先的方式：在工作流中不编辑文件，也不实现修复。
用途 当用户请求调查某类失败时，该技能通过四个只读子智能体并行排查，再由主智能体对可能原因进行排序，并推荐最快的验证或修复路径。
使用方式 第一步：构建 Bug 包（Bug Packet）。收集最小可用的调查材料，包括症状、预期行为、实际行为、已知复现步骤、影响范围，以及日志、堆栈、失败测试、截图、近期 diff、环境细节等相关证据。来源优先级为：用户直接描述、用户明确提供的文件/堆栈/日志/测试/截图、出现回归迹象时的当前 git 变更或近期仓库历史、围绕失败点的最小相关代码路径或子系统。如果报告不够具体，则推断最小问题陈述并说明仍未知的部分。在启动子智能体之前，阅读受影响区域最近的项目说明和相关文档，例如 AGENTS.md、仓库工作流文档，以及受影响子系统的架构、状态、路由、schema 或运行时文档。
第二步：界定调查范围。为群体编写简短的调查简报，说明看起来哪里坏了、尚未证明什么、最可能涉及系统哪一部分、已有哪些证据、何种证据算作确认。可使用只读证据收集手段，如 rg、git diff、git log、git show，阅读日志、崩溃堆栈和配置，运行已有测试或最小安全复现命令。不得编辑文件、注入新埋点或实现修复。
第三步：并行启动四个只读调查者。当问题足够大或模糊、并行调查有帮助时启动四个子智能体；对于极小且明显的问题，可以本地调查。每个子智能体都需获得相同的 Bug 包和调查简报，明确其只读属性，不得编辑文件、运行 apply_patch、暂存变更、提交或执行任何改变状态的操作，只返回简洁的调查输出：假设、支持证据、缺失证据、最小验证步骤和置信度；避免泛泛的代码质量反馈、挑剔或没有证据的猜测；只把发现送回主智能体。四个角色分别为：1）复现与范围调查，澄清失败的确切形态和边界，检查最窄可靠触发条件、使问题出现或消失的条件、失败边界上的预期与实际行为，以及影响是局部的、跨切的、确定性的还是偶发的；2）代码路径与失败切面调查，追踪最可能的执行路径并找出行为发生分歧的切面，检查状态转换、生命周期边界或顺序问题，调用方与被调方假设不匹配，数据流或控制流断裂，以及最可能负责失败的最小代码区域；3）近期变更与回归调查，在附近历史或变更契约中寻找可能的回归源，检查与症状相关的近期 diff、配置/开关/依赖/schema/迁移漂移、本应一起变更的部分更新，以及符合 bug 报告时间点的行为变化；4）取证计划与可观测性调查，确定确认或排除主要假设的最快方式，检查应失败的最小已有测试或复现、当前最有用的日志/追踪/指标/断言、能快速提升信心的最小非变更命令，以及缺失哪些证据及如何在不大量扰动的情况下收集。只报告能实质提高找到真实原因概率的假设；两个有证据支撑的理论优于六个模糊猜测。
第四步：综合并排序假设。主智能体负责综合，将子智能体输出视为原始调查输入而非最终输出，合并重复项、丢弃薄弱推测、优先证据而非优雅、区分可能根因与单纯促成因素、仅在备选理论仍合理时保留。将存留假设规范为：假设、支持证据、缺失或冲突证据、最小验证步骤、置信度（高/中/低）。如果证据太弱无法真正排序，直接说明并给出主要开放问题。
第五步：输出清晰的诊断路径。按以下顺序呈现：最可能根因、合理的备选原因（如有）、最快验证步骤、建议修复路径、开放问题或阻碍。当修复尚不明确时，推荐下一步验证步骤，而不是假装诊断已完成。可分组为：现在证明、接下来修复、稍后跟进。该技能不实现修复，输出是只读诊断及优先级明确的后续路径。
适用场景 适用于需要诊断优先、证据驱动、并行排查的 bug、回归、崩溃、偶发行为或无法解释的失败场景。
限制 该技能不编辑文件、不注入埋点、不实现修复；子智能体只读；输出仅为诊断和建议路径。资料未提供其收费、价格、平台支持或具体安装命令等信息。