Qa

---
name: qa
description: Conversational QA mode — user reports bugs in plain language, agent clarifies minimally, files GitHub issues that survive refactors. Trigger on "QA", "QA session", or ad-hoc bug reporting without a fixed deliverable shape. Distinct from branch-scoped and PR-scoped review.
---

Run an interactive QA session. The user describes problems. You clarify lightly, explore the codebase in the background for domain language, and file issues that are durable and user-focused. Each issue is independent — never batch.

## For Each Reported Issue

### 1. Listen, lightly clarify

Let the user describe the problem in their own words. Ask **at most 2-3 short questions**, only on:
- Expected vs actual behavior
- Steps to reproduce (if not already obvious)
- Consistent vs intermittent

Do NOT over-interview.

### 2. Explore in background

Dispatch an Explore agent in parallel while the user talks. Goal is **NOT** to find a fix — it is to:
- Learn the domain language used in that area (read `UBIQUITOUS_LANGUAGE.md` if present)
- Understand what the feature is supposed to do
- Identify the user-facing behavior boundary

Context informs the issue body; the issue body itself does NOT cite files, line numbers, or internal module names.

### 3. Assess scope

Single issue or breakdown? Break down when fix spans multiple independent areas, separable concerns parallelize across people, or user describes multiple distinct failure modes.

### 4. File via `gh issue create`

Do NOT ask the user to review the body first — file it, share URLs.

**Issue body rules:**
- No file paths, no line numbers
- Use the project's domain language; never internal symbol names
- Describe behavior, not code: "the sync service fails to apply the patch", not "applyPatch() throws on line 42"
- Reproduction steps are mandatory
- 30-second readability — concise

### Single-Issue Template

```
## What happened
Plain-language actual behavior.

## What I expected
Plain-language expected behavior.

## Steps to reproduce
1. Concrete step using domain terms
2. Concrete step
3. Concrete step (include relevant inputs/flags)

## Additional context
Observations from the user or background exploration.
```

## Reproduction-Step Examples

**Web app:**
1. Sign in as a Pro-tier user
2. Open the export dialog from the Reports tab
3. Choose CSV format and click Export
4. Observe: download fails silently with no toast.

**CLI tool:**
1. Run `mycli migrate --target=v3 --dry-run`
2. Pipe stderr to a file
3. Observe: stderr contains a stack trace despite `--dry-run`.

## Continuation

Keep going until the user signals done. One issue per round-trip. Never batch.

## Modality Differentiation Appendix

| Skill            | Scope                              | Trigger                                       | Artifact                                      |
| ---------------- | ---------------------------------- | --------------------------------------------- | --------------------------------------------- |
| **qa**           | Ad-hoc conversational exploration  | User-driven, free-form bug reports            | Multiple GitHub issues per session            |
| *branch review*  | Active branch diff vs base         | Explicit invocation on current work           | Single structured review report               |
| *PR review*      | A specific GitHub PR vs its base   | PR URL or number, runs `gh pr view`           | PR comments + summary report                  |

Use **qa** when the user is exploring; use branch review when finishing branch work; use PR review when reviewing someone else's PR.