用途：对一个已报告的缺陷或问题进行分诊，探索代码库找到根因，然后创建带有 TDD 修复计划的 GitHub issue。适合用户报告 bug 或希望把排查结果整理成可执行修复方案时使用。流程尽量少向用户提问，属于基本放手执行的工作流。
主要能力：先用一个问题获取问题描述，若用户未提供则只问“What's the problem you're seeing?”，随后立即开始调查。使用 Agent 工具并以 subagent_type=Explore 深入探索代码库，目标是找到问题表现入口、涉及代码路径、根因以及相关代码与测试，并查看相关源码与依赖、现有测试、受影响文件的近期变更（git log）和错误处理。接着确定最小修复改动、受影响的模块与接口、需通过测试验证的行为，并判断这是回归、缺失功能还是设计缺陷。
TDD 修复计划：按 RED-GREEN 循环给出有序的垂直切片清单。每条 RED 描述一个捕获破坏或缺失行为的测试，每条 GREEN 描述让该测试通过的最小代码改动。规则包括：测试通过公共接口验证行为而非实现细节；一次一个测试，垂直切片，不是先写全部测试再写全部代码；每个测试应能经受内部重构；必要时包含最终重构步骤。修复建议应像规格说明，描述行为与契约，而非内部结构；测试断言可观察结果，如 API 响应、UI 状态、用户可见效果。
创建 issue：使用 gh issue create 按模板创建 GitHub issue，不先请用户审阅，直接创建并分享 URL。模板包含 Problem（实际行为、预期行为、复现方式）、Root Cause Analysis（涉及代码路径、失败原因、促成因素，但不含具体文件路径、行号或耦合当前代码布局的实现细节）、TDD Fix Plan（编号的 RED-GREEN 循环，可含 REFACTOR）以及 Acceptance Criteria（验收标准、所有新测试通过、现有测试仍通过）。创建后打印 issue URL 和根因的一句话摘要。
适用场景与限制：适合缺陷分诊与修复计划制定。资料未提供具体平台支持范围、依赖安装方式、收费或价格信息；使用 gh 命令需要相应 GitHub 环境与权限，具体配置暂未提供。