# QA

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

- Skill: `karasukaigan/qa` (Agent Skill)
- Install (CLI): `npx skillmds@latest add karasukaigan/qa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/karasukaigan/qa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: karasukaigan (https://skillmd.com/u/karasukaigan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/karasukaigan/qa

---


# QA 会话

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

## 对于用户提出的每个问题

### 1. 倾听并轻微澄清

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

- 他们的预期与实际发生的情况
- 重现步骤（如果不明显）
- 是否一致还是间歇性出现

不要过度询问。如果描述足够清晰可以提交，就继续。

### 2. 在后台探索代码库

在与用户交谈时，在后台启动一个 Agent（subagent_type=Explore）来理解相关区域。目标不是找到修复方案——而是：

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

这些上下文有助于你编写更好的 issue——但 issue 本身不应引用特定文件、行号或内部实现细节。

### 3. 评估范围：单个 issue 还是需要拆分？

在提交之前，决定这是**单个 issue** 还是需要**拆分**成多个 issue。

以下情况需要拆分：

- 修复涉及多个独立区域（例如"表单验证错误 AND 缺少成功消息 AND 重定向损坏"）
- 存在明显可分离的关注点，不同的人可以并行处理
- 用户描述的内容有多个不同的失败模式或症状

以下情况保持为单个 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**——每个都应该可以独立修复和验证
- **诚实地标记阻塞关系**——如果 issue B 在 issue A 修复之前确实无法测试，请说明。如果它们是独立的，将两者都标记为"无——可以立即开始"
- **按依赖顺序创建 issue**，以便你可以在"阻塞于"中引用真实的 issue 编号
- **最大化并行性**——目标是多个人（或代理）可以同时处理不同的 issue

#### 所有 issue 正文的规则

- **没有文件路径或行号**——这些会过时
- **使用项目的领域语言**（如果存在，检查 UBIQUITOUS_LANGUAGE.md）
- **描述行为，而不是代码**——"同步服务无法应用补丁"而不是"applyPatch() 在第 42 行抛出异常"
- **重现步骤是必需的**——如果你无法确定它们，询问用户
- **保持简洁**——开发人员应该能够在 30 秒内阅读 issue

提交后，打印所有 issue URL（总结阻塞关系）并询问："下一个 issue，还是我们完成了？"

### 5. 继续会话

持续进行直到用户说他们完成了。每个 issue 都是独立的——不要批量处理它们。