用途：运行一次交互式 QA 会话，让用户用自然语言描述问题，由智能体整理并直接提交到 GitHub Issues。
主要能力与流程：
- 倾听并轻度澄清。让用户用自己的话描述问题，最多追问 2-3 个简短问题，聚焦预期与实际行为的差异、复现步骤、问题是稳定出现还是偶发。描述足够清晰就不再继续追问。
- 后台探索代码库。在对话同时启动 Explore 子智能体了解相关区域，目的是学习该领域的领域语言（可查看 UBIQUITOUS_LANGUAGE.md）、理解功能应做什么、识别面向用户的行为边界；探索不是为了找修复方案，issue 本身也不应引用具体文件、行号或内部实现细节。
- 判断范围。若修复横跨多个独立区域、存在可并行处理的可分离关注点、或有多种不同失败模式，就拆分为多个 issue；若只是单一位置的一个行为错误、症状由同一根因导致，则保持单个 issue。
- 创建 GitHub issue。使用 gh issue create，不要求用户先审阅，直接创建并分享链接。单条 issue 模板含 What happened、What I expected、Steps to reproduce、Additional context。拆分时按依赖顺序创建（阻塞项在前），子 issue 模板含 Parent issue、What's wrong、What I expected、Steps to reproduce、Blocked by、Additional context；倾向多而薄、每个可独立修复验证，如实标注阻塞关系，最大化并行。
对所有 issue 的规则：不写文件路径或行号（会过时）；使用项目领域语言；描述行为而非代码；复现步骤必填，无法确定就向用户询问；保持简洁，开发者 30 秒内可读完。创建后打印所有 issue URL 及阻塞关系摘要，并询问“下一个问题，还是结束？”
适用场景：项目质量反馈、缺陷梳理、把口头报告转为结构化可跟踪的 GitHub issue。
限制与说明：依赖 gh CLI 与 GitHub 仓库环境；需要用户提供可辨别的复现步骤；资料未提供其他平台支持、安装方式、收费或价格信息，这些暂未提供。