用途：处理 Bug 报告、测试失败、意外行为、性能问题、构建失败等。核心主张是先建立可靠反馈循环、定位根因，再动手修复，避免随机试错。入口为 Bug 报告或失败信号，出口为复现测试通过并生成根因记录。
主要能力：四阶段必须按序推进。Phase 1 根因调查：完整读错误信息与堆栈、稳定复现、构建最小复现、查最近变更（git diff、提交、依赖、配置、环境），跨组件系统加诊断埋点并向上追溯数据流。Phase 2 模式分析：找工作示例、完整阅读参考实现、逐条列出差异、理解依赖与假设。Phase 3 假设与验证：写出单一假设（“我认为 X 是根因，因为 Y”），最小化测试、一次只变一个变量，未确认则换假设。Phase 4 修复：先写失败复现测试（RED），再做单一修复，验证（GREEN）且无回归。若修复连续失败三次，进入 Phase 4.5 架构质疑门，与人类讨论后再继续。另提供测试失败、构建失败、运行时错误的分类诊断路径与安全降级模式。
使用方式：前置加载 CANON.md 与 build-quality-tdd/SKILL.md；Phase 1-3 用 templates/bug/01-root-cause.md 落盘到 docs/bugs/<name>/01-root-cause.md，Phase 4 用 templates/bug/02-fix-plan.md 落盘到 docs/bugs/<name>/02-fix-plan.md，之后回到 build-workflow-execute 或 verify-workflow-review。根因记录需含 Status Summary、症状、影响范围、时间线、复现步骤与证据、调查过程、根因、非根因排除、修复方向、Done When；修复计划需含 Status Summary、修复目标、最小改动范围、复现测试、修复步骤、验证计划、回归风险、Follow-up Actions、Done When。
适用场景：代码库中的可复现缺陷、跨组件故障定位、需要留下可验证根因记录的团队流程。限制：已文档化的预期行为、简单重试即可解决的环境问题不适用；无法稳定复现时须先收集更多数据，不可猜测。具体安装命令与收费信息暂未提供。