Debug Mode 是一套面向缺陷排查的技能，核心主张是“用运行时证据调试，而不是靠猜测”。它指出仅靠静态代码分析容易让代理自信地给出并未被运行时数据支持的修复方案，从而反复失败；因此要求先采集变量取值、代码路径、事件顺序与错误抛出位置等实际运行数据。
主要能力与流程：
- 以 /debug-mode 调用，先静默启动日志收集器，命令为 curl -s http://127.0.0.1:7777/health || bun ./scripts/start-collector.mjs。若调用时带参数（如 /debug-mode color picker doesn't save changes），则将其作为缺陷报告直接进入假设生成；未带参数时先向用户询问预期与实际的差异、复现方式、报错或症状及相关文件。
- 生成 3 到 5 条具体、可验证的假设，并用编号（A、B、C 等）标识，例如“未提供 order.items 时 items 为 undefined”或“竞态：loadUser 在 renderProfile 之后完成”。
- 对这些假设并行插桩，使用基于 fetch 的 __debugLog 记录器向 http://127.0.0.1:7777/ingest 发送含 location、hypothesisId、message、data、level、timestamp 的 JSON；插入点包括函数出入口、条件分支、异步操作前后、错误捕获块与状态变更。文档强调必须使用该 fetch 记录器，因为它同时适用于浏览器与服务端；客户端代码绝不能使用 node:fs 导入，否则会导致浏览器崩溃。
- 提供具体、编号的复现步骤并放在 <reproduction_steps> 标签内，步骤需针对当前缺陷而非通用占位；先运行 bun ./scripts/clear-logs.mjs 清除旧日志。若改动了后端代码，需提醒用户重启服务。完成后提示用户运行 /debug-reproduced，若问题已解决则运行 /debug-fixed。
关键规则：没有运行时证据不得修复；每次日志调用都要带假设字母；禁止记录密码、令牌、个人信息或 API 密钥等敏感数据；存疑时应增加插桩而非猜测。文档同时说明修复常需迭代，首次修复失败属正常，每次失败都提供新数据以缩小根因范围，不应一次失败就放弃。
限制与暂未提供的信息：除上述流程外，官方来源未提供安装方式、平台与运行环境要求、收费与价格、日志收集器的实现细节及数据存储方式等，此处不再展开。