用途
troubleshoot 是一个系统化调试技能，用于处理 spaces/[project]/ 目录中出现的问题。当遇到 bug、测试失败或意外行为时使用。它通过一个五步循环来组织调试过程，避免盲目猜测。
主要能力
核心是五步循环：研究（Research）→ 假设（Hypothesize）→ 实现（Implement）→ 测试（Test）→ 记录（Document）。如果问题未修复，则回到第一步重复循环。
各步骤要点：
- 研究：在猜测之前先理解问题。检查已有研究文档（resources/research/.md、ideas/[project]/notes/research/.md），在代码库中搜索相似问题（Grep spaces/[project]/ 中的错误信息），通过 Context7 查看库文档，用 WebSearch 搜索错误信息和已知问题。对于不熟悉的错误信息、库/框架行为或模式的最佳实践，可启动 research-specialist 智能体。
- 假设：一次只形成一个假设，并列出证据和调试计划。多个理论会导致混乱。
- 实现：应用修复并添加调试日志，例如 console.log('[Auth] State before query:', authState)。
- 测试：验证修复，运行特定测试（npm test -- --grep "auth"）、完整测试套件（npm test），必要时手动验证（npm run dev）。测试未通过前绝不声称已修复。
- 记录：在 WORKLOG 中更新发现，包括假设、调试发现、实现、结果和注意事项。
使用方式
命令用法示例：
- /troubleshoot yourbench "tests failing after auth changes"
- /troubleshoot yourbench 001（在某个 issue 的上下文中调试）
- /troubleshoot coordinatr（通用调试会话）
执行模式有两种：
- 模式一：在 TASK 实现过程中调试。读取 TASK.md、PLAN.md、WORKLOG.md 获取上下文，执行五步循环，在 issue 的 WORKLOG.md 中记录，修复后继续 /implement。
- 模式二：独立调试。在没有 issue 上下文的情况下调查，记录发现，如果问题严重则建议创建 BUG issue。
工作流：/implement →（出现问题）→ /troubleshoot → /worklog → /implement。修复后添加 WORKLOG 条目，继续实现；若问题反复出现则创建 BUG issue。
关键规则
- 先研究再猜测
- 一次只验证一个假设
- 充分添加调试日志
- 测试未通过前绝不声称已修复
- 失败时先回滚（git checkout -- .）再进行下一次尝试
- 记录所有内容以备将来参考
适用场景
适用于在 spaces/[project]/ 中遇到 bug、测试失败或意外行为时的调试工作，既可在任务实现过程中使用，也可作为独立调试会话使用。
限制
资料未提供该技能的安装方式、依赖要求、支持的平台或收费信息。