用途：当用户报告 bug、崩溃、报错或行为异常，或验证阶段失败且失败路径尚不清楚时，先调用 taku-debug，而不是直接写修复代码。它用于解释“为什么失败”，再提出修复。常规验证应先跑仓库自带检查，检查失败或生产已出问题时才进入本技能。
主要能力：以四阶段流程推进。第一阶段 INVESTIGATE 收集证据：完整读错误与堆栈、稳定复现、检查近期改动（如 git log --oneline -20 -- <affected-files>、git diff HEAD~1 -- <affected-files>）、反向追踪坏值来源，并在多层系统中于各边界加诊断日志。第二阶段 PATTERN 对照已知失败模式，如竞态、空值传播、状态损坏、集成失败、配置漂移、缓存过期，并查看同仓库正确示例、TODOS.md、git log 及 .taku/learnings/{project-slug}.jsonl。第三阶段 HYPOTHESIS 按可能性排序假设，一次只测一个变量；若三个假设均失败则停止，考虑换理论、升级人工或加埋点。第四阶段 IMPLEMENT 先写失败测试，再做最小修复，跑全量测试，并检查影响范围。
核心约束：铁律是“未完成根因调查前不得修复”。写任何代码改动前必须完成前三阶段，并产出 DEBUG REPORT，包含症状、根因、假设、修复、证据、回归测试与状态（DONE、DONE_WITH_CONCERNS、BLOCKED）。
适用场景：回归、间歇性问题、多组件系统故障、需要先解释失败原因再修复的调试任务。
限制：资料未提供安装命令、平台支持、收费方式与具体集成细节；若修复涉及超过 5 个文件或跨 3 个以上子系统，应暂停并说明理由或拆分修复。