用途
这是一个交互式 QA 会话技能。用户以对话方式报告遇到的 bug 或问题，智能体负责澄清问题、在后台探索代码库获取上下文，并最终提交 GitHub issue。目标是产出持久、面向用户、使用项目领域语言的 issue。
主要能力
- 以对话方式接收用户的问题描述，进行轻量澄清。
- 在后台启动探索型子智能体（subagent_type=Explore）了解相关区域，目的不是找修复方案，而是学习该区域的领域语言（检查 UBIQUITOUS_LANGUAGE.md）、理解功能预期行为、识别面向用户的行为边界。
- 评估问题范围：判断应作为单个 issue 还是拆分为多个 issue。
- 使用 gh issue create 提交 GitHub issue，不要求用户先审阅，直接提交并分享 URL。
- 支持单个 issue 模板与拆分（多个 issue）模板，并处理阻塞依赖关系。
- 会话持续进行，直到用户表示结束。
使用方式
1. 倾听并轻量澄清
让用户用自己的话描述问题。最多问 2-3 个简短的澄清问题，聚焦于：
- 用户期望什么 vs 实际发生了什么
- 复现步骤（如果不明显）
- 问题是一致出现还是间歇出现
不要过度访谈。如果描述足够清晰可以提交，就继续下一步。
2. 在后台探索代码库
在与用户交谈的同时，在后台启动一个 Agent（subagent_type=Explore）来理解相关区域。目标不是找到修复方案，而是：
- 学习该区域使用的领域语言（检查 UBIQUITOUS_LANGUAGE.md）
- 理解该功能应该做什么
- 识别面向用户的行为边界
这些上下文有助于写出更好的 issue，但 issue 本身不应引用具体文件、行号或内部实现细节。
3. 评估范围：单个 issue 还是拆分？
提交前，判断这是单个 issue 还是需要拆分为多个 issue。
需要拆分的情况：
- 修复涉及多个独立区域（例如“表单验证错误，且成功消息缺失，且重定向损坏”）
- 存在明显可分离的关注点，不同人可以并行处理
- 用户描述的内容有多个不同的失败模式或症状
保持为单个 issue 的情况：
- 是某一处的一个行为错误
- 所有症状都由同一个根行为引起
4. 提交 GitHub issue
使用 gh issue create 创建 issue。不要要求用户先审阅——直接提交并分享 URL。
Issue 必须持久——在重大重构后仍应说得通。从用户视角撰写。
单个 issue 模板：
## What happened
[用平实语言描述用户实际经历的行为]
## What I expected
[描述期望的行为]
## Steps to reproduce
1. [开发者可以遵循的具体编号步骤]
2. [使用代码库中的领域术语，而非内部模块名]
3. [包含相关输入、标志或配置]
## Additional context
[来自用户或代码库探索的任何额外观察，有助于框定问题——例如“这只在使用 Docker 层时发生，而非文件系统层”——使用领域语言但不要引用文件]
拆分（多个 issue）模板：
按依赖顺序创建 issue（阻塞项优先），以便引用真实的 issue 编号。
每个子 issue 使用此模板：
## Parent issue
#<parent-issue-number>（如果你创建了跟踪 issue）或“Reported during QA session”
## What's wrong
[描述这个具体的行为问题——只描述这一片，而非整个报告]
## What I expected
[这一片的期望行为]
## Steps to reproduce
1. [针对此 issue 的步骤]
## Blocked by
- #<issue-number>（如果此 issue 在另一个解决前无法修复）
或“None — can start immediately”（如果没有阻塞项）
## Additional context
[与此片相关的任何额外观察]
创建拆分时：
- 倾向于多个薄 issue 而非少数厚 issue——每个都应可独立修复和验证
- 如实标记阻塞关系——如果 issue B 确实在 issue A 修复前无法测试，就说明。如果相互独立，两者都标记为“None — can start immediately”
- 按依赖顺序创建 issue，以便在“Blocked by”中引用真实 issue 编号
- 最大化并行性——目标是多个人（或智能体）可以同时领取不同的 issue
所有 issue 正文的规则：
- 不包含文件路径或行号——这些会过时
- 使用项目的领域语言（如果存在 UBIQUITOUS_LANGUAGE.md 则检查）
- 描述行为，而非代码——“同步服务未能应用补丁”而非“applyPatch() 在第 42 行抛出异常”
- 复现步骤是强制性的——如果无法确定，询问用户
- 保持简洁——开发者应能在 30 秒内读完 issue
提交后，打印所有 issue URL（并总结阻塞关系），然后询问：“Next issue, or are we done?”
5. 继续会话
持续进行，直到用户表示结束。每个 issue 相互独立——不要批量处理。
适用场景
- 用户希望以对话方式报告 bug 或问题，并由智能体代为提交 GitHub issue。
- 需要将复杂问题拆分为多个可独立修复、可并行处理的 issue。
- 需要写出持久、面向用户、使用领域语言的 issue，避免引用易过时的内部实现细节。
限制
- 依赖 gh issue create 命令提交 issue，需要相应的 GitHub 环境与权限。
- 复现步骤是强制性的，若无法确定需询问用户。
- Issue 正文不得包含文件路径或行号。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。