用途：对用户报告的 bug 或问题进行分诊，先探索代码库找到根因，再创建一个包含 TDD 修复计划的 GitHub issue。整体为尽量少打扰用户的工作流，减少提问。
主要能力与流程：
- 捕获问题：获取用户对问题的简要描述；若未提供，只问一个问题“What's the problem you're seeing?”，不追问，立即开始调查。
- 探索与诊断：使用 Agent 工具并设置 subagent_type=Explore 深入调查代码库，目标是找到 bug 表现位置（入口点、UI、API 响应）、涉及的代码路径、失败根因（而非仅症状）、相关代码（相似模式、测试、相邻模块）。查看相关源文件及依赖、现有测试、受影响文件的近期变更（git log）、代码路径中的错误处理、代码库中正常工作的相似模式。
- 确定修复方向：判断修复根因所需的最小改动、受影响的模块/接口、需通过测试验证的行为，以及这是回归、缺失功能还是设计缺陷。
- 设计 TDD 修复计划：给出具体有序的 RED-GREEN 循环，每个循环是一个垂直切片。RED 描述捕获损坏/缺失行为的具体测试；GREEN 描述让该测试通过的最小代码改动。规则：测试通过公共接口验证行为而非实现细节；一次一个测试，垂直切片（不是先写全部测试再写全部代码）；每个测试应能经受内部重构；必要时包含最终重构步骤。持久性要求：只建议能经受代码库大幅变化的修复，描述行为与契约而非内部结构；测试断言可观察结果（API 响应、UI 状态、用户可见效果），不针对内部状态。好的建议读起来像规格说明，差的像 diff。
- 创建 GitHub issue：使用 gh issue create 按模板创建，不要求用户先审阅，直接创建并分享 URL。模板包含 Problem（实际行为、期望行为、复现方式）、Root Cause Analysis（涉及的代码路径、当前代码为何失败、促成因素；不包含具体文件路径、行号或与当前代码布局耦合的实现细节，而描述模块、行为与契约，使 issue 在大重构后仍有用）、TDD Fix Plan（编号的 RED-GREEN 循环，最后可加 REFACTOR）、Acceptance Criteria（各项标准、所有新测试通过、现有测试仍通过）。创建后打印 issue URL 和根因的一行摘要。
适用场景：用户报告 bug、希望调查问题并生成带修复计划的 GitHub issue 时。
限制：资料未提供安装方式、收费、价格、支持平台或效果保证等信息；使用需具备可访问的代码库、Agent 工具与 gh CLI 环境。