用途：运行一场交互式 QA 会话。用户用自己的话描述遇到的问题，代理负责澄清、在后台探索代码库获取上下文，并提交以用户视角撰写、可长期有效的 GitHub Issue。
主要流程与能力：
- 倾听与轻度澄清：最多提 2-3 个简短问题，聚焦期望与实际差异、复现步骤、问题是否稳定复现；描述足够清楚就直接进入下一步，不过度盘问。
- 后台探索代码库：与用户交谈的同时，启动 Agent（subagent_type=Explore）了解相关区域，目的是学习该领域的领域术语（可查看 GLOSSARY.md）、理解功能应做什么、识别面向用户的行为边界。探索只为写出更好的 Issue，Issue 本身不引用具体文件、行号或内部实现细节。
- 判断范围：判断是单个 Issue 还是需要拆分。跨多个独立区域、存在可并行处理的可分离关注点、或存在多个不同失败模式时应拆分；单一位置的一种错误行为、症状同源时保持单 Issue。
- 提交 Issue：用 gh issue create 创建，不先让用户审阅，直接提交并分享 URL。单个 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，如实标注阻塞关系，以最大化并行。
所有 Issue 正文规则：不写文件路径或行号；使用项目领域语言；描述行为而非代码；复现步骤必需，无法确定时向用户询问；保持简洁，30 秒内可读完。提交后打印所有 Issue URL 与阻塞关系摘要，并询问“Next issue, or are we done?”。
限制：需持续会话直到用户表示结束，每个 Issue 独立处理不做批处理；依赖 gh 命令与 GitHub 环境。其余如定价、平台支持等暂未提供。