用途
QA Session 用于开展一次交互式的质量保障会话。用户以日常对话的方式描述自己遇到的问题，代理负责澄清、在后台探索代码库以获取上下文，并提交持久、以用户为中心且使用项目领域语言的 GitHub issue。
主要能力
- 以对话方式收集用户报告的 bug 或问题，适量澄清（最多 2-3 个简短问题），关注期望与实际行为、复现步骤、问题是稳定还是偶发。
- 在对话的同时，后台启动 Agent（subagent_type=Explore）了解相关区域，学习该区域的领域语言（检查 UBIQUITOUS_LANGUAGE.md），理解功能预期行为，识别面向用户的行为边界。
- 判断单个问题应作为单一 issue 还是拆分为多个 issue：当修复涉及多个独立区域、存在可并行处理的可分离关注点、或用户描述包含多个不同失败模式或症状时拆分；当问题只是某一处单一行为错误或所有症状源于同一根因行为时保持为单一 issue。
- 使用
gh issue create提交 GitHub issue，不要求用户先审核，直接提交并分享 URL。
使用方式
针对用户提出的每个问题：
- 倾听并轻度澄清。让用户用自己的话描述问题。最多问 2-3 个简短澄清问题，聚焦于期望与实际发生、复现步骤（若不明显）、是否稳定复现。不要过度采访；若描述足以提交则继续。
- 后台探索代码库。目标不是找修复，而是学习领域语言、理解功能本应做什么、识别面向用户的行为边界。这些上下文帮助写出更好的 issue，但 issue 本身不应引用具体文件、行号或内部实现细节。
- 评估范围：单一 issue 还是拆分。
- 提交 GitHub issue。
单一 issue 的模板：
## What happened
[用平实语言描述用户实际经历的行为]
## What I expected
[描述期望的行为]
## Steps to reproduce
1. [开发者可以遵循的具体编号步骤]
2. [使用代码库中的领域术语，而非内部模块名]
3. [包含相关输入、标志或配置]
## Additional context
[用户或代码库探索中的任何额外观察，有助于框定该问题——例如“这只在使用 Docker 层时发生，而非文件系统层”——使用领域语言但不要引用文件]
拆分（多个 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 以便在 “Blocked by” 中引用真实 issue 编号；最大化并行度，目标是多个人（或代理）可以同时认领不同 issue。
所有 issue 正文的规则：不要包含文件路径或行号（会过时）；使用项目领域语言（若存在则检查 UBIQUITOUS_LANGUAGE.md）；描述行为而非代码（“同步服务无法应用补丁”而非“applyPatch() 在第 42 行抛出异常”）；复现步骤为必填，若无法确定则询问用户；保持简洁，开发者应能在 30 秒内读完。
提交后，打印所有 issue URL（并总结阻塞关系），询问：“Next issue, or are we done?”
- 继续会话。直到用户表示结束。每个 issue 相互独立，不要批量处理。
适用场景
适用于在软件开发项目中通过自然对话收集 bug 报告并自动转化为规范 GitHub issue 的流程，尤其适合需要多人或代理并行处理、强调以用户视角描述问题和持久可维护性的团队。
限制
该技能依赖 GitHub CLI（gh issue create）创建 issue；后台探索使用 Explore 子代理；issue 不包含文件路径或行号，因此不提供代码级定位；若无法确定复现步骤，需要用户补充。资料未提供该技能的具体安装方式、依赖版本、收费情况或平台限制。