qa

name	qa
description	交互式 QA 会话，用户以对话方式报告 bug 或问题，代理负责提交 GitHub issue。会在后台探索代码库以获取上下文和领域语言。当用户想报告 bug、做 QA、以对话方式提交 issue，或提到 "QA session" 时使用。

QA 会话

运行一个交互式 QA 会话。用户描述他们遇到的问题。你负责澄清、探索代码库以获取上下文，并提交持久、以用户为中心、使用项目领域语言的 GitHub 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

使用以下模板：

## 发生了什么

[用平实的语言描述用户实际经历的行为]

## 我期望的是什么

[描述期望的行为]

## 复现步骤

1. [开发者可以照着做的具体、编号步骤]
2. [使用代码库中的领域术语，而非内部模块名]
3. [包含相关的输入、标志或配置]

## 补充上下文

[来自用户或代码库探索的任何额外观察，有助于界定该 issue——例如"这只在使用 Docker 层时发生，文件系统层不会"——使用领域语言，但不要引用文件]

对于拆分（多个 issue）

按依赖顺序创建 issue（先创建阻塞项），以便你能引用真实的 issue 编号。

每个子 issue 使用以下模板：

## 父 issue

#<父 issue 编号>（如果你创建了一个跟踪 issue），或"在 QA 会话期间报告"

## 哪里出错了

[描述这一具体的行为问题——只针对这一片，而非整个报告]

## 我期望的是什么

[这一具体片段的期望行为]

## 复现步骤

1. [针对这个 issue 的步骤]

## 被以下阻塞

- #<issue 编号>（如果这个 issue 在另一个解决之前无法修复）

如果没有阻塞项，则填"无——可立即开始"。

## 补充上下文

[与这一片相关的任何额外观察]

创建拆分时：

• 宁愿多个薄 issue，也不要少数厚 issue——每个都应可独立修复和验证
• 如实标注阻塞关系——如果 issue B 在 issue A 修复前确实无法测试，就说明。如果它们相互独立，就把两者都标为"无——可立即开始"
• 按依赖顺序创建 issue，以便在"被以下阻塞"中引用真实的 issue 编号
• 最大化并行度——目标是让多人（或多个代理）能够同时认领不同的 issue

所有 issue 正文的通用规则

• 不要写文件路径或行号——它们会过时
• 使用项目的领域语言（若存在 UBIQUITOUS_LANGUAGE.md 则查看它）
• 描述行为，而非代码——写"同步服务无法应用补丁"，而不是"applyPatch() 在第 42 行抛出异常"
• 复现步骤是必需的——如果你无法确定，就询问用户
• 保持简洁——开发者应能在 30 秒内读完该 issue

提交后，打印所有 issue 的 URL（并总结阻塞关系），然后询问："下一个 issue，还是我们就到这儿？"

5. 继续会话

持续进行直到用户表示完成。每个 issue 都是独立的——不要把它们攒到一起处理。