qa

name	qa
description	Interactive QA session: the user reports bugs or issues conversationally, the agent clarifies, explores the codebase in the background for domain language, and files durable, user-focused issues on the project tracker. Triggers on: "QA session", "let's do QA", "file an issue for this", "report a bug", "log these bugs", "bug triage", or when the user describes problems they want captured as tracker issues rather than fixed immediately.
license	MIT (adapted from mattpocock/skills)

QA Session

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

The issue tracker should have been provided to you — run /setup-project-skills if not. File to the agent work tracker it names: these issues are agent-created, so they belong there even though the reports originate with a human. If no tracker has been provided, default to the local-markdown tracker.

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 (read the project's domain glossary — CONTEXT.md unless the domain doc config points elsewhere — if one exists)
• 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 issue(s)

Create issues per the tracker doc's "publish to the issue tracker" convention. Do NOT ask the user to review first — just file and share URLs.

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 (check the domain glossary if one exists)
• 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.