用途：运行交互式 QA 会话，让用户用自己的话描述遇到的问题，代理负责澄清、探索代码库、并提交 GitHub Issue。
主要能力与流程：
- 倾听并适度澄清：最多提 2-3 个简短问题，聚焦期望与实际结果的差异、复现步骤、问题是否稳定复现；描述足够清晰即进入下一步。
- 后台探索代码库：以 Explore 子代理了解相关区域，学习领域语言（查看 UBIQUITOUS_LANGUAGE.md）、理解功能应有的行为、识别用户可见的行为边界；目的是写好 Issue，而非找修复方案。
- 评估范围：判断是单个 Issue 还是需拆分（多个独立区域、可分离关注点、多种故障模式时拆分；同一行为同一处出错则保持单个）。
- 提交 GitHub Issue：使用 gh issue create，不先让用户审核，直接提交并分享 URL。
- 继续会话：直至用户表示完成，每个 Issue 独立处理，不批量。
单个 Issue 模板包含：发生了什么、我期望的结果、复现步骤、附加上下文。拆分时按依赖顺序创建（阻塞者优先），子 Issue 包含父 Issue、问题描述、期望结果、复现步骤、被阻塞者、附加上下文；应宁愿多而薄，如实标记阻塞关系，最大化并行度。
所有 Issue 正文规则：不包含文件路径或行号，使用项目领域语言，描述行为而非代码，复现步骤必须（无法确定时向用户提问），保持简洁（30 秒内读完）。提交后打印所有 URL 并总结阻塞关系，询问“下一个 Issue，还是结束了？”。
适用场景：报告 bug、进行 QA、以对话形式提交 Issue，或用户提到 QA session。
限制：资料未提供具体收费、价格、支持平台、安装方式等细节，暂未提供。