用途：适用于原因不确定、难以稳定复现的缺陷，以及性能回退类问题。若已有跟踪、失败测试或直接代码证据能确定原因，则直接做经授权的窄修复并验证原始症状，不必额外制造假设或缩小已能定位故障的复现。
主要能力：探索代码库时读取 CONTEXT.md（若存在）以建立相关模块的心智模型，并查看所触及领域的 ADR。整个流程分六个阶段。第一阶段搭建反馈回路，这是技能核心：需要一条对本缺陷会变红、确定、快速且可无人值守运行的命令，手段可选失败测试（单元／集成／端到端）、curl 或 HTTP 脚本、带夹具输入并与已知良好快照对比 diff 的 CLI 调用、Playwright 或 Puppeteer 无头浏览器脚本、重放抓取的网络请求／载荷／事件日志、一次性最小夹具、属性或模糊循环、二分夹具、新旧版本差异循环，最后才是人工介入脚本 scripts/hitl-loop.template.sh。回路要持续收紧：更快、信号更锐利、更确定。非确定性缺陷要寻求可测量的复现率并在授权测试环境内控制负载。无法搭建回路时须明说并列出已尝试内容，请求最小缺失材料或权限，同时继续只读工作：查看日志与跟踪、走静态代码路径、比对近期改动、形成按证据排序的假设并标注未验证；新增生产埋点仍需授权。第二阶段复现并最小化，确认失败模式与用户描述一致、可多次复现、已捕获确切症状；逐个削减输入、调用方、配置、数据与步骤，保留承载故障的部分。第三阶段提出可证伪假设，格式为“若 是原因，则 会让缺陷消失／更糟”，无法给出预测则弃用。第四阶段埋点，每个探针对应一个预测，一次只改一个变量；优先调试器／REPL，其次在区分假设的边界做定向日志，每条调试日志加唯一前缀如 [DEBUG-a4f2] 以便清理；性能分支应先建立基线测量再二分。第五阶段修复并补回归测试，先写测试但仅在存在正确缝（能按调用点真实模式复现）时进行；若无正确缝，这本身即是发现，应记录并移交后续阶段。第六阶段清理与复盘，须确认原始复现不再出现、回归测试通过或已记录缺失缝、所有 [DEBUG-...] 埋点已删除、一次性原型已删除或移入明确标记位置、正确的假设已写入提交或 PR 消息；再思考什么能预防该缺陷，若涉及架构改动（缺少良好测试缝、调用方纠缠、隐藏耦合）则移交 /improve-codebase-architecture 技能。限制：资料未提供具体收费、价格、支持平台与效果数据；所有修复与生产埋点均需授权。