用途
该技能用于运行一次交互式 QA（质量保障）会话。用户以对话方式描述自己遇到的问题，AI 负责澄清问题、在后台探索代码库获取上下文，并提交到 GitHub issue 中。其目标是让 issue 持久、面向用户，并使用项目自身的领域语言表述。
主要能力
针对用户提出的每个问题，技能按以下流程处理：
1. 倾听并轻度澄清
让用户用自己的话描述问题。最多问 2-3 个简短的澄清问题，聚焦于：预期与实际发生的情况、复现步骤（如果不明显）、问题是稳定复现还是偶发。不要过度追问——如果描述已足够清楚可以直接提交，就继续下一步。
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
- [开发者可遵循的具体编号步骤]
- [使用代码库中的领域术语，而非内部模块名]
- [包含相关输入、标志或配置]
Additional context
[来自用户或代码库探索的额外观察，用于框定问题——例如「这只在使用 Docker 层时发生，而非文件系统层」——使用领域语言但不引用文件]
拆分（多个 issue）的模板：
按依赖顺序创建 issue（阻塞项在前），以便引用真实的 issue 编号。每个子 issue 使用以下模板：
Parent issue
#<父 issue 编号>（如果你创建了跟踪 issue）或「Reported during QA session」
What's wrong
[描述这个具体的行为问题——只描述这一块，而非整个报告]
What I expected
[针对这一块的期望行为]
Steps to reproduce
- [针对本 issue 的具体步骤]
Blocked by
- #<issue 编号>（如果该 issue 需要等其他 issue 解决后才能修复）
或「None — can start immediately」表示无阻塞。
Additional context
[与本块相关的额外观察]
创建拆分时应：优先采用多个薄 issue 而非少数厚 issue——每个都应可独立修复和验证；如实标注阻塞关系——如果 issue B 确实要等 issue A 修复后才能测试，就说明；若彼此独立，都标注「None — can start immediately」；按依赖顺序创建 issue，以便在「Blocked by」中引用真实编号；最大化并行度——目标是让多个人（或智能体）能同时领取不同 issue。
**所有 issue 正文的规则：**不要包含文件路径或行号（会过时）；使用项目的领域语言（若存在 UBIQUITOUS_LANGUAGE.md 则检查）；描述行为而非代码——例如「同步服务无法应用补丁」而非「applyPatch() 在第 42 行抛出异常」；复现步骤是必需的——如果无法确定，需询问用户；保持简洁——开发者应能在 30 秒内读完。
提交后，打印所有 issue 的 URL（并概述阻塞关系），然后询问：「Next issue, or are we done?」（下一个问题，还是到此为止？）
5. 继续会话
持续进行，直到用户表示完成。每个 issue 都是独立的——不要批量处理。
使用方式
该技能在对话式 QA 会话中被触发，用户描述问题，AI 依上述流程澄清、后台探索、判断范围并调用 gh issue create 提交 issue，最后输出 URL 并询问是否继续。
适用场景
适合开发团队在迭代过程中以对话方式快速收集、澄清并归档用户反馈和缺陷，尤其适用于希望通过 GitHub issue 跟踪、并要求 issue 在大规模重构后仍保持有效的团队。
限制
该技能依赖 gh（GitHub CLI）命令创建 issue；issue 正文不引用文件路径或行号，因此不适合需要精确定位代码位置的场景；关于具体收费、价格、支持平台等信息，暂未提供。