用途：运行一次交互式 QA 会话。用户用自己的话描述遇到的问题，代理负责澄清、后台探索代码库上下文，并创建持久、面向用户、使用项目领域语言的 GitHub issue。
主要流程与能力：
- 倾听并轻度澄清：让用户自行描述问题，最多问 2-3 个简短问题，聚焦于期望与实际行为的差异、复现步骤（若不明显）、问题是稳定复现还是偶发。描述足够清楚就直接进入下一步，不要过度盘问。
- 后台探索代码库：在对话的同时启动一个 subagent_type=Explore 的后台代理，目的是了解该区域的领域语言（可查看 UBIQUITOUS_LANGUAGE.md）、功能本应做什么、面向用户的行为边界。此上下文只用于写出更好的 issue，issue 本身不应引用具体文件、行号或内部实现细节。
- 评估范围：决定是单个 issue 还是需拆分。当修复跨越多个独立区域、存在可分离且可由不同人并行处理的关注点、或用户描述包含多个不同失败模式时，应拆分为多个 issue；当只是一个地方的一种行为出错、症状由同一根因导致时，保持单个 issue。
- 创建 GitHub issue：使用 gh issue create，不让用户先审阅，直接创建并分享 URL。issue 必须持久，重构后仍能理解，从用户视角撰写。单个 issue 模板包含 What happened、What I expected、Steps to reproduce、Additional context。拆分时按依赖顺序创建（阻塞项在前），以便引用真实 issue 编号，每个子 issue 模板包含 Parent issue、What's wrong、What I expected、Steps to reproduce、Blocked by（无阻塞则写 None — can start immediately）、Additional context。拆分原则：宁多而薄，每个可独立修复和验证；如实标注阻塞关系；最大化并行。
- 所有 issue 正文规则：不写文件路径或行号（会过时）；使用项目领域语言；描述行为而非代码；必须提供复现步骤，无法确定时向用户询问；保持简洁，开发者 30 秒内可读完。创建后打印所有 issue URL 并汇总阻塞关系，询问“Next issue, or are we done?”。
- 持续会话直到用户表示结束，每个 issue 独立处理，不要批量合并。
限制与依赖：需要可用 GitHub CLI（gh）且已具备创建 issue 的权限；需存在可探索的代码库；UBIQUITOUS_LANGUAGE.md 为可选。资料未提供具体收费、平台支持范围及失败处理细节。