用途：diagnose 用于找出产生缺陷的机制，而非直接修复。它接受缺陷报告、错误信息、异常行为、截图、日志、堆栈、复现步骤、失败测试，或本地 issue、spec、ticket、PR、commit、分支、文件路径等输入，也可接受来自 triangulate-diagnosis 的诊断视角（repro-first、data-flow、recent-change/environment）。当症状或目标仓库区域过于模糊时，只提一个简洁问题，否则基于明确假设继续。
主要能力：先写工作简报，记录观察行为、预期行为、受影响入口、约束与非目标、已有证据；再构建反馈回路，优先使用已有失败测试、新增针对性失败测试或最小脚本、命令、curl 请求、fixture、回放、手动序列；随后检查输入、持久状态、配置、环境、特性开关、调用方与被调方、错误处理、回退路径、缓存、时序与并发，以及近期变更、迁移、依赖或部署差异；接着列出候选机制，预测证据并做最小验证，记录被排除的假设；最后定位根因，指出源文件、模块、接口、数据边界或配置来源，若多个原因仍合理则报告分歧。
使用方式：按诊断报告结构输出，包含根因、证据、已构建的反馈回路、修复位置与思路、被排除的替代方案、置信度。若用户同时要求实现，先完成诊断，再按请求进入修复或 to-spec、to-tickets、execute-ticket 流程。
限制：不将“代码看起来可疑”当作证据；无法构建反馈回路时只推进到识别缺失工件或访问权限，并标记低置信度；除非用户明确要求，否则不编辑文件。涉及密钥时须先脱敏，用 <REDACTED> 替换密钥值与含密参数，保留最小非密上下文；若脱敏后无法区分剩余假设，应停在边界处，仅请求安全脱敏的工件或另行授权的插桩，绝不索取、回显或持久化原始密钥。
适用场景：适合单缺陷的根因定位、复现验证、数据流追踪与近期变更排查。具体收费、价格、平台支持等信息暂未提供。