用途：cb-fix 用于在范围明确、风险可控时执行缺陷修复，强调根因分析与修复后验证，而非症状性打补丁。
适用前提（启动前必须全部满足）：存在具体问题信号（明确的失败行为、错误或回归，且有日志、堆栈、失败测试或可复现步骤等证据）；修复路径可能局部化（问题限于小范围，无需跨系统重构或迁移，架构风险低到中等）；验证路径直接（可在实际范围内复现并验证成功标准）。任一条件不满足，应升级到 brainstorm 或 write-plan。
硬性停止与升级条件：聚焦调查后根因仍不清晰；修复需要跨领域架构或数据模型变更；范围扩大为大型重构或多模块迁移；涉及安全/合规敏感行为；验证发现需要分阶段缓解的广泛回归；多次修复尝试仍未收敛到根因。此时应停止实现，并输出指定消息：“This fix exceeds safe single-pass debugging limits. Ask, Recommend brainstorm or write-plan first to define phased diagnosis, implementation, and risk controls.”
工作流程：1）接收与情境化，明确预期行为，收集最小缺陷报告字段（标题、预期行为、实际行为、复现步骤、证据、环境、影响/严重度），并按共享 Context Loading Protocol 加载项目上下文；2）复现与诊断，稳定复现，定位失败点，追踪控制/数据流找出根因，形成能解释现象的修复假设；3）判断小修还是大修，小修继续本技能，大修按硬性停止条件升级；4）实现小修，给出 1-3 条简要计划，做最小针对性修改，保持范围严格，必要时补充回归测试；5）验证，按范围递增运行聚焦检查、邻近回归检查及项目检查（lint/typecheck/tests/build），复现不再失败、预期行为确认且无关键回归才算完成；6）完成并报告，说明根因、改动内容、为何有效、验证结果与残余风险/后续事项，必要时更新最小相关文档。
规则：关键上下文缺失时不要猜测，应通过 Question Tool 询问；始终优先根因修复；保持影响范围最小；未验证不得标记完成；范围或风险超出本技能时尽早升级。资料还提供可选的缺陷报告模板，用于报告不完整时补齐字段。