QA

QA Session

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

Required tools

• mcp__linear-server__save_issue — create issues
• mcp__linear-server__list_teams — discover the team to file against
• mcp__linear-server__list_issue_labels — check available labels

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 (check UBIQUITOUS_LANGUAGE.md)
• 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 Linear issue(s)

Create issues using mcp__linear-server__save_issue. Do NOT ask the user to review first — just file and share the identifiers.

If you haven't already, use mcp__linear-server__list_teams to determine the correct team.

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

For a single issue

Use this as the issue description:

## 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 a parent issue first, then create sub-issues using parentId set to the parent issue identifier. Create in dependency order (blockers first) so you can set blockedBy with real issue identifiers.

Use this template for each sub-issue description:

## 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]

## 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
• Set blocking relationships honestly using blockedBy — if issue B genuinely can't be tested until issue A is fixed, say so
• Create issues in dependency order so you can reference real identifiers in blockedBy
• 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 UBIQUITOUS_LANGUAGE.md if it 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 identifiers (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.