qa

name	qa
description	交互式 QA 会话，用户以对话方式报告 bug 或问题，agent 将其录入 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. [包含相关的输入、标志或配置]

## 补充上下文

[来自用户或代码库探索的任何额外观察，有助于框定问题 — 例如 "这仅在 Docker 层出现，文件系统层不会" — 使用领域语言但不要引用文件]

拆解为多个 issue

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

对每个子 issue 使用以下模板：

## 父 issue

#<父 issue 编号>（如果你创建了跟踪 issue）或 "QA 会话中报告"

## 出了什么问题

[描述这个具体的行为问题 — 仅此一个切面，不是整个报告]

## 我期望的结果

[此具体切面的预期行为]

## 复现步骤

1. [针对此 issue 的具体步骤]

## 被阻塞

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

或 "无 — 可立即开始"（如果没有阻塞项）。

## 补充上下文

[与此切面相关的任何额外观察]

拆解时：

• 优先使用多个薄 issue 而非少数厚 issue — 每个应可独立修复和验证
• 如实标注阻塞关系 — 如果 issue B 在 issue A 修复之前确实无法测试，如实标注。如果它们是独立的，两者都标为 "无 — 可立即开始"
• 按依赖顺序创建 issue，以便在"被阻塞"中可以引用真实的 issue 编号
• 最大化并行性 — 目标是多个人（或 agent）可以同时拿取不同的 issue

所有 issue 正文的规则

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

录入后，打印所有 issue URL（附阻断关系摘要）并询问："下一个 issue，还是到此结束？"

5. 继续会话

持续进行直到用户说结束。每个 issue 是独立的 — 不要批处理它们。