用途：对用户报告的 bug 或问题做分诊——在代码库中调查根因，并创建一个包含 TDD 修复计划的 GitHub issue。整个流程尽量少提问、少人工干预。
使用方式：先获取问题简述；若用户未提供，只问一句“你看到的问题是什么？”，随后立即开始调查，不再追问。接着使用 Agent 工具并设置 subagent_type=Explore 深入探索代码库，目标是找到缺陷显现位置（入口、UI、API 响应）、涉及代码路径、失败根因（而非症状）以及相关代码（相似模式、测试、相邻模块）。调查内容包括相关源文件及依赖、现有测试的覆盖与缺口、受影响文件的近期改动（对相关文件执行 git log）、代码路径中的错误处理，以及代码库中运行正常的相似模式。
随后确定修复思路：修复根因所需的最小改动、受影响的模块与接口、需通过测试验证的行为，并判断问题属于回归、缺失功能还是设计缺陷。再设计按 RED-GREEN 循环排列的 TDD 计划，每个循环是一个垂直切片：RED 描述捕获错误或缺失行为的具体测试，GREEN 描述让该测试通过的最小代码改动。规则是测试通过公共接口验证行为而非实现细节；一次一个测试、垂直切片而不是先写全部测试；测试应能经受内部重构；必要时在最后加一步 REFACTOR。建议只保留能经受代码库大幅变化的修复，描述行为与契约，而非内部结构；测试断言可观察结果（API 响应、UI 状态、用户可见效果），而非内部状态。
最后使用 gh issue create 按模板创建 GitHub issue，不需要用户先审阅，创建后直接分享 URL。issue 包含 Problem（实际行为、期望行为、复现方式）、Root Cause Analysis（涉及的代码路径、当前代码为何失败、促成因素，但不要包含具体文件路径、行号或与当前代码布局耦合的实现细节）、TDD Fix Plan（编号的 RED-GREEN 循环，必要时附 REFACTOR）以及 Acceptance Criteria（各验收标准、所有新测试通过、现有测试仍通过）。创建 issue 后，打印 issue URL 和一行根因摘要。
适用场景：用户报告 bug、希望排查问题根因并形成可执行修复计划时。限制：官方资料未提供更多关于依赖环境、平台支持或收费的信息，暂未提供。