| 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 都是独立的 -- 不要批量处理它们.
