qa

name	qa
description	交互式 QA 会话, 用户以对话方式报告 bug 或问题, agent 提交 GitHub issues. 在后台探索代码库以获取上下文和领域语言. 当用户想要报告 bug, 进行 QA, 以对话方式提交 issues, 提到 "问题反馈", "提 bug" 或 "QA session" 时使用.

QA 会话

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

对于用户提出的每个问题

1. 倾听并轻度澄清

让用户用自己的话描述问题.** 最多问 2-3 个简短的澄清问题**, 重点关注:

• 他们期望什么 vs 实际发生了什么
• 重现步骤(如果不明显)
• 是否一致或间歇性

不要过度访谈. 如果描述足够清晰可以提交, 继续前进.

2. 在后台探索代码库

在与用户交谈时, 在后台启动一个 Agent(subagent_type=Explore)以了解相关区域. 目标不是找到修复 -- 而是:

• 学习该区域使用的领域语言(检查 UBIQUITOUS_LANGUAGE.md)
• 了解功能应该做什么
• 识别面向用户的行为边界

这个上下文帮助你编写更好的 issue -- 但 issue 本身不应该引用特定文件, 行号或内部实现细节.

3. 评估范围: 单个 issue 还是分解?

在提交之前, 决定这是否是单个 issue 还是需要分解为多个 issues.

在以下情况下分解:

• 修复跨越多个独立区域(例如 "表单验证错误 AND 缺少成功消息 AND 重定向损坏")
• 有明显可分离的关注点, 不同的人可以并行工作
• 用户描述的内容有多个不同的故障模式或症状

在以下情况下保持为单个 issue:

• 在一个地方一个行为错误
• 所有症状都由相同的根本行为引起

4. 提交 GitHub issue(s)

使用 gh issue create 创建 issues. 不要先要求用户审查 -- 只需提交并分享 URL.

Issues 必须是持久的 -- 即使在重大重构后它们也应该有意义. 从用户的角度编写.

对于单个 issue

使用此模板:

## 发生了什么

[用简单语言描述用户体验的实际行为]

## 我期望的结果

[描述预期行为]

## 复现步骤

1. [开发者可以遵循的具体编号步骤]
2. [使用代码库中的领域术语, 而不是内部模块名称]
3. [包含相关输入, 标志或配置]

## 附加上下文

[来自用户或代码库探索的任何额外观察, 帮助框定 issue -- 例如 "这仅在使用 Docker layer 时发生, 而不是 filesystem layer" -- 使用领域语言但不引用文件]

对于分解(多个 issues)

按依赖顺序创建 issues(阻塞者优先), 以便你可以引用真实的 issue 编号.

对每个子 issue 使用此模板:

## 父 issue

#<parent-issue-number>(如果你创建了跟踪 issue)或"在 QA 会话期间报告"

## 问题是什么

[描述这个特定的行为问题 -- 只是这个切片, 而不是整个报告]

## 我期望的结果

[此特定切片的预期行为]

## 复现步骤

1. [特定于此 issue 的步骤]

## 阻塞于

- #<issue-number>(如果此 issue 在另一个 issue 解决之前无法修复)

或"无 -- 可以立即开始", 如果没有阻塞者.

## 附加上下文

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

创建分解时:

• 优先选择多个薄 issues 而非少数厚 issues -- 每个应该是可独立修复和验证的
• 诚实地标记阻塞关系 -- 如果 issue B 在 issue A 修复之前确实无法测试, 请说明. 如果它们是独立的, 将两者标记为"无 -- 可以立即开始"
• 按依赖顺序创建 issues, 以便你可以在"阻塞于"中引用真实的 issue 编号
• 最大化并行性 -- 目标是多个人(或 agents)可以同时认领不同的 issues

所有 issue 正文的规则

• 没有文件路径或行号 -- 这些会过时
• 使用项目的领域语言(如果存在 UBIQUITOUS_LANGUAGE.md, 请检查)
• 描述行为, 而不是代码 -- "sync service 无法应用补丁" 而不是 "applyPatch() 在第 42 行抛出"
• 重现步骤是强制性的 -- 如果你无法确定它们, 询问用户
• 保持简洁 -- 开发者应该能够在 30 秒内阅读 issue

提交后, 打印所有 issue URL(带有阻塞关系摘要)并询问: "下一个 issue, 还是我们完成了?"

5. 继续会话

继续直到用户说他们完成了. 每个 issue 都是独立的 -- 不要批量处理它们.