kscz0000 缺陷猎杀群组
适用场景
当你需要对 Bug、回归、崩溃、偶发行为或无法解释的失败进行并行只读多智能体根因调查时，请使用本技能。在用户要求调查 Bug、查找根因、追溯回归、理解为何崩溃，或想要附带...的排名诊断时使用。
并行启动四个只读子智能体调查 Bug，再由主智能体对可能的原因进行排序，并推荐最快可证明或修复该问题的路径。本技能以诊断优先：在本工作流中不要编辑文件或实施修复。
第一步：构建缺陷信息包
首先收集最小且有用的调查信息包：
- 现象
- 预期行为
- 实际行为
- 复现步骤（若已知）
- 影响范围
- 相关证据，例如日志、堆栈跟踪、失败测试、截图、最近的 diff 或环境细节
优先采用以下来源顺序：
- 用户的直接描述
- 用户提供的明确文件、堆栈跟踪、日志、测试或截图
- 当 Bug 表现为回归时，查看当前 git 变更或最近仓库历史
- 围绕失败点的最小相关代码路径或子系统
如果 Bug 报告描述不充分，则推断出最小的问题陈述，并说明尚不清楚之处。
在启动子智能体之前，先阅读与受影响区域最相关的项目指令和文档，例如：
AGENTS.md- 仓库工作流文档
- 受影响子系统的架构、状态、路由、模式或运行时文档
第二步：界定调查范围
为该调查群组撰写一份简短的调查简报：
- 看起来损坏的是什么
- 尚未被证实的是什么
- 系统中最可能涉及的部分
- 已存在的证据
- 什么样的证据可算作确认
在有用处使用只读证据收集手段：
rg、git diff、git log、git show- 阅读日志、崩溃跟踪和配置
- 已有的测试运行或最小且安全的复现命令
在本技能中不要编辑文件、注入新的检测代码或实施修复。
第三步：并行启动四个只读调查员
当问题足够大或足够模糊，以至于并行调查能带来帮助时，启动四个子智能体。对于微小且明显的问题，直接在本地调查也是可接受的。
对每个子智能体：
- 提供相同的缺陷信息包和调查简报
- 声明该子智能体为只读
- 不允许该子智能体编辑文件、运行
apply_patch、暂存变更、提交，或执行任何其他会改变状态的操作 - 只要求简洁的调查输出
- 要求其提供：假设、支持证据、缺失证据、最小证明步骤以及置信度
- 告知子智能体避免泛泛的代码质量反馈、吹毛求疵或缺乏证据的猜测
- 告知子智能体只将发现反馈给主智能体
使用以下四个调查角色。
子智能体一：复现与范围调查
厘清确切的失败形态及其边界。
需检查：
- 最窄且最可靠的触发条件
- 让 Bug 出现或消失的条件
- 失败边界处的预期与实际行为对比
- 影响是局部的、跨模块的、确定性的，还是偶发的
该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。
推荐的子智能体角色：reviewer
子智能体二：代码路径与故障接缝调查
追踪最可能的执行路径，并定位行为发生偏离的接缝。
需检查：
- 状态转换、生命周期边界或顺序问题
- 调用方与被调用方之间不匹配的假设
- 数据流或控制流的中断
- 最可能对此次失败负责的最小代码区域
该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。
推荐的子智能体角色：用于广泛追踪时使用 explorer，当更需要进行深入的本地推理时使用 reviewer
子智能体三：近期变更与回归调查
在附近的历史或变更后的契约中查找可能的回归源。
需检查：
- 与该现象在时间上相关的最近 diff
- 配置、标志、依赖、模式或迁移的漂移
- 多个入口本应同步更新却只完成部分更新的情况
- 与 Bug 报告时间吻合的行为变更
该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。
推荐的子智能体角色：reviewer
子智能体四：证明计划与可观测性调查
确定确认或否定主要假设的最快方式。
需检查：
- 应当失败的最小现有测试或复现
- 最有用的当前日志、跟踪、指标或断言
- 一个能快速提高置信度的最小非破坏性命令
- 缺失哪些证据，以及如何在不造成大范围干扰的情况下收集它们
该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。
推荐的子智能体角色：reviewer
仅报告能实质提升找到真正原因概率的假设。返回两个有证据支撑的理论，远胜于返回六个含糊的猜测。
第四步：综合得出排序后的假设
综合工作由主智能体负责。将子智能体的输出视为原始调查输入，而非最终输出。
合并并对假设进行排序：
- 合并重复项
- 剔除薄弱的猜测
- 偏好证据胜过简洁
- 将可能的根本原因与单纯的诱因区分开
- 仅在仍有合理性时保留备选理论
将保留下来的假设规范化为以下结构：
- 假设
- 支持证据
- 缺失或冲突的证据
- 最小证明步骤
- 置信度：高、中或低
如果证据过于薄弱而无法真正排序，请直接说明，并改为提出主要的悬而未决的问题。
第五步：输出一条清晰的诊断路径
按以下顺序呈现结果：
- 最可能的根本原因
- 合理的备选原因（若有）
- 最快的证明步骤
- 推荐的修复路径
- 悬而未决的问题或阻碍
当修复尚不明朗时，推荐下一步的证明步骤，而不是假装诊断已经完成。
在合适时，可将动作归类为：
prove now（立即证明）fix next（下一步修复）follow up later（稍后跟进）
在本技能中不要实施修复。输出是一份带优先级路径的只读诊断。
局限
- 仅当任务明确匹配其上游来源和本地项目上下文时，才使用本技能。
- 在应用变更之前，请验证命令、生成的代码、依赖、凭证以及外部服务的行为。
- 不要把示例当作针对特定环境的测试、安全审查或用户对破坏性或高成本操作的批准之替代品。