qa

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

QA 会话（QA Session）

运行交互式 QA 会话。用户描述他们遇到的问题。你进行澄清，探索代码库以获取上下文，然后提交持久、以用户为中心、并使用项目领域语言的 GitHub Issue。

针对用户提出的每个问题

1. 倾听并适度澄清

让用户用自己的话描述问题。最多提出 2-3 个简短的澄清问题，重点关注：

• 他们期望的结果与实际发生的结果之间的差异
• 复现步骤（如果不明显的话）
• 问题是稳定复现还是间歇性出现

不要过度追问。如果描述足够清晰可以提交 Issue，就继续下一步。

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. [包含相关的输入、标志或配置]

## 附加上下文

[来自用户或代码库探索的任何额外观察，有助于界定问题——例如"仅在使用 Docker layer 时发生，使用 filesystem layer 时不会"——使用领域语言，但不要引用文件"]

拆分为多个 Issue

按依赖顺序创建 Issue（阻塞者优先），以便你可以引用真实的 Issue 编号。

每个子 Issue 使用以下模板：

## 父 Issue

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

## 问题描述

[描述这个具体的行为问题——仅限这一部分，不是整个报告]

## 我期望的结果

[针对这一部分的期望行为]

## 复现步骤

1. [仅针对此 Issue 的步骤]

## 被阻塞者

- #<Issue 编号>（如果此 Issue 需要先解决另一个 Issue 才能修复）

如果没有阻塞者，填写"无——可以立即开始"。

## 附加上下文

[与此部分相关的任何额外观察]

创建拆分 Issue 时：

• 宁愿多而薄，不要少而厚——每个 Issue 应能独立修复和验证
• 如实标记阻塞关系——如果 Issue B 确实需要 Issue A 修复后才能测试，就如实说明。如果它们相互独立，都标记为"无——可以立即开始"
• 按依赖顺序创建 Issue——这样你可以在"被阻塞者"中引用真实的 Issue 编号
• 最大化并行度——目标是让多人（或多个 Agent）可以同时处理不同的 Issue

所有 Issue 正文的规则

• 不包含文件路径或行号——这些会过时
• 使用项目的领域语言（查看 UBIQUITOUS_LANGUAGE.md 如果存在的话）
• 描述行为，而非代码——"同步服务无法应用补丁"而不是"applyPatch() 在第 42 行抛出异常"
• 复现步骤是必须的——如果你无法确定，向用户提问
• 保持简洁——开发者应在 30 秒内读完 Issue

提交后，打印所有 Issue URL（并总结阻塞关系），然后询问："下一个 Issue，还是结束了？"

5. 继续会话

持续进行，直到用户表示完成。每个 Issue 都是独立的——不要批量处理。