用途：当出现症状但原因不明、间歇性或环境相关失败、性能回归、反复复发，需要复现、最小化与假设验证时使用。若原因与修复方式已明确（如条件写反、缺少 prop、明显漏掉的分支），则不要使用。
主要流程：反馈回路 → 复现 → 最小化 → 排序假设（3–5 个，含可反驳预测）→ 插桩观测（每次只改一个变量）→ 修复 → 回归验证 → 清理。反馈回路需满足：抓住用户真实症状、可由 agent 重跑、至少实际执行一次、能给出 red/green 判定、尽量快速可重复。在满足这五个条件之前，不要确认假设或打补丁；无法满足时以 Blocked 或 Unverifiable 停止，并报告已尝试方法、缺失的环境或制品、所需日志/HAR/fixture/trace/权限。
验证与提交：清理掉临时插桩后再跑原始复现与回归缝，只有 clean-state 的 green 才能作为完成与提交依据；清理前后前提变化或失败复现，须丢弃先前的 green。若用户显式独立调用本技能且确实改了代码，同时满足根因修复完成、原始复现 green、回归验证成功、清理后 clean-state 验证成功、工作 diff 可与现有用户改动分离时，才在当前分支 commit；若 tk-implement 仍在进行，则不要单独 commit，交回其最终验证与提交。未获单独请求不要 push、PR、merge、tag、release 或 publish。
限制：不得在复现前猜测性打补丁、未反驳就确认原因，或制造虚假信心的测试；不得留下临时插桩或一次性调试制品；不要在诊断期间先做架构重构。资料未提供具体命令或代码示例。