01
这个 skill 做什么
对本地 branch 或未提交改动执行窄范围 Bugbot 工作流时使用此 skill。检测会盘点 tracked 与 untracked 文件，递归追踪 diff 派生候选项直到有界固定点，并把每个已验证的生产 Bug 写入唯一 Markdown 报告；该报告是检测阶段唯一允许的写入。修复意图来自完整对话，也包括首次请求中的评审并修复授权。报告落盘后继续已授权修复，无需再次批准；只要求评审时停在报告。修复意图明确且没有更窄范围时，选择最新无歧义报告中的全部未解决 findings；具体语义指代可以选择子集。运行相关及必需检查，不静默处理不同的新 findings，也不改变 Git 发布状态。
02
什么时候使用
- 01针对仓库默认分支或指定 base 审查当前 branch work。
- 02针对 HEAD 审查 staged、unstaged 与 untracked 本地改动。
- 03生成不限 finding 数量的持久报告，再根据上下文识别的意图修复全部或选定 findings。
03
如何工作
- 01
解析仓库、比较模式、baseline、tracked diff 与 untracked 文件清单。
- 02
从每个 changed hunk 与 untracked 文件建立候选前沿。
- 03
只沿与改动有因果关系的控制流、依赖、契约、状态和失败路径追踪候选项。
- 04
持续加入新暴露的 diff 相关风险直到固定点，再按根因验证和去重。
- 05
把每个已验证 finding 写入带稳定报告内 ID、证据、coverage 与 recommendation 的唯一 Markdown 报告。
- 06
报告落盘后沿用首次请求或后续对话中的修复授权，重新验证选定 findings，完成针对性及必需检查，避免无依据重复验证。
04
你会得到什么
- 01一份持久 Markdown 报告，包含每个引入生产 Bug 的 finding card 与完整索引。
- 02完整审查无 Bug 时的明确 clean report，或列出精确 coverage gaps 的 incomplete report。
- 03修复后的 Markdown 摘要，包含验证结果与仍未确认的问题。
05
重要边界
- 01检测期间只写报告 artifact；不要编辑被审查源码或 Git 状态。
- 02只为 Bugbot 请求启动新检测；隐式路由用于报告跟进，而不是普通 code review。
- 03从当前及之前的用户指令识别修复意图，保留只评审的范围；只有意图、报告或 finding 范围仍存在关键歧义时才询问。
- 04不要限制 findings 数量，也不要在最高严重度或最容易的问题后停止。
- 05不要把递归前沿扩展到与被审查改动没有因果关系的路径。
- 06不要 stage、commit、push、deploy，或在没有单独请求时修复不同的新 findings。
06