qa

name	qa
description	Run a conversational QA session — the user describes bugs one at a time, and each becomes a durable, user-focused GitHub issue written in the project's own domain language, broken into parallelizable sub-issues when it spans separable concerns. Use when the user wants to report bugs, walk through problems they hit while using the product, file issues conversationally, or mentions a QA session. Use log-seeker instead when the goal is to diagnose a failure rather than record it.
allowed-tools	Bash, Read, Grep, Glob, Agent

QA Session

Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and file GitHub issues that are durable, user-focused, and use the project's domain language.

Confirm the destination once, at the start. Say which repo the issues will be filed against and get a go-ahead before the first gh issue create. Filing to a public tracker is externally visible and awkward to undo, and the fast loop below only works if that question is settled up front rather than re-asked for every issue.

For each issue the user raises

1. Listen and lightly clarify

Let the user describe the problem in their own words. Ask at most 2-3 short clarifying questions focused on:

• What they expected vs what actually happened
• Steps to reproduce (if not obvious)
• Whether it's consistent or intermittent

Do NOT over-interview. If the description is clear enough to file, move on.

2. Explore the codebase in the background

While talking to the user, kick off an Agent (subagent_type=Explore) in the background to understand the relevant area. The goal is NOT to find a fix — it's to:

• Learn the domain language used in that area (the canonical contracts under docs/plan/ and the wiki under docs/wiki/ are where Alt's vocabulary is defined)
• Understand what the feature is supposed to do
• Identify the user-facing behavior boundary

This context helps you write a better issue — but the issue itself should NOT reference specific files, line numbers, or internal implementation details.

3. Assess scope: single issue or breakdown?

Before filing, decide whether this is a single issue or needs to be broken down into multiple issues.

Break down when:

• The fix spans multiple independent areas (e.g. "the form validation is wrong AND the success message is missing AND the redirect is broken")
• There are clearly separable concerns that different people could work on in parallel
• The user describes something that has multiple distinct failure modes or symptoms

Keep as a single issue when:

• It's one behavior that's wrong in one place
• The symptoms are all caused by the same root behavior

4. File the GitHub issue(s)

Create issues with gh issue create. Once the destination is confirmed, don't ask for per-issue review — file and share the URL, so the session keeps its rhythm.

Issues must be durable — they should still make sense after major refactors. Write from the user's perspective.

For a single issue

Use this template:

## What happened

[Describe the actual behavior the user experienced, in plain language]

## What I expected

[Describe the expected behavior]

## Steps to reproduce

1. [Concrete, numbered steps a developer can follow]
2. [Use domain terms from the codebase, not internal module names]
3. [Include relevant inputs, flags, or configuration]

## Additional context

[Any extra observations from the user or from codebase exploration that help frame the issue — e.g. "this only happens when using the Docker layer, not the filesystem layer" — use domain language but don't cite files]

For a breakdown (multiple issues)

Create issues in dependency order (blockers first) so you can reference real issue numbers.

Use this template for each sub-issue:

## Parent issue

#<parent-issue-number> (if you created a tracking issue) or "Reported during QA session"

## What's wrong

[Describe this specific behavior problem — just this slice, not the whole report]

## What I expected

[Expected behavior for this specific slice]

## Steps to reproduce

1. [Steps specific to THIS issue]

## Blocked by

- #<issue-number> (if this issue can't be fixed until another is resolved)

Or "None — can start immediately" if no blockers.

## Additional context

[Any extra observations relevant to this slice]

When creating a breakdown:

• Prefer many thin issues over few thick ones — each should be independently fixable and verifiable
• Mark blocking relationships honestly — if issue B genuinely can't be tested until issue A is fixed, say so. If they're independent, mark both as "None — can start immediately"
• Create issues in dependency order so you can reference real issue numbers in "Blocked by"
• Maximize parallelism — the goal is that multiple people (or agents) can grab different issues simultaneously

Rules for all issue bodies

• No file paths or line numbers — these go stale
• Use the project's domain language (as defined in docs/plan/ contracts and docs/wiki/)
• Describe behaviors, not code — "the sync service fails to apply the patch" not "applyPatch() throws on line 42"
• Reproduction steps are mandatory — if you can't determine them, ask the user
• Keep it concise — a developer should be able to read the issue in 30 seconds

After filing, print all issue URLs (with blocking relationships summarized) and ask: "Next issue, or are we done?"

5. Continue the session

Keep going until the user says they're done. Each issue is independent — don't batch them.