/team-qa

name: team-qa
description: "Orchestrate the QA team through a full testing cycle. Coordinates qa-lead (strategy + test plan) and qa-tester (test case writing + bug reporting) to produce a complete QA package for a sprint or feature. Covers: test plan generation, test case writing, smoke check gate, manual QA execution, and sign-off report."
argument-hint: "[sprint | feature: system-name] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion
model: sonnet
agent: qa-lead

When this skill is invoked, orchestrate the QA team through a structured testing cycle.

**Decision Points:** At each phase transition, use `AskUserQuestion` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase.

Phase 0: Resolve Review Mode

1. If `--review [mode]` was passed as an argument, use that mode. 2. Else read `production/review-mode.txt` — use whatever is written there. 3. Else default to `lean`.

Modes:

• `full` — spawn all director and lead gates as described
• `lean` — skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
• `solo` — skip all director gate spawning entirely; run the skill without any agent gates

Store the resolved mode for use in all subsequent phases.

Team Composition

• **qa-lead** — QA strategy, test plan generation, story classification, sign-off report
• **qa-tester** — Test case writing, bug report writing, manual QA documentation

How to Delegate

Use the Task tool to spawn each team member as a subagent:

• `subagent_type: qa-lead` — Strategy, planning, classification, sign-off
• `subagent_type: qa-tester` — Test case writing and bug report writing

Always provide full context in each agent's prompt (story file paths, QA plan path, scope constraints). Launch independent qa-tester tasks in parallel where possible (e.g., multiple stories in Phase 5 can be scaffolded simultaneously).

Pipeline

Phase 1: Load Context

Before doing anything else, gather the full scope:

1. Detect the current sprint or feature scope from the argument:

• If argument is a sprint identifier (e.g., `sprint-03`): Glob `production/sprints/` for files matching `*[sprint-identifier]*.md`. Read the matched file. If multiple match, use the most recently modified.
• If argument is `feature: [system-name]`: glob story files tagged for that system
• If no argument: read `production/session-state/active.md` and `production/sprint-status.yaml` (if present) to infer the active sprint

2. Read `production/stage.txt` to confirm the current project phase.

3. Count stories found and report to the user: > "QA cycle starting for [sprint/feature]. Found [N] stories. Current stage: [stage]. Ready to begin QA strategy?"

Phase 2: QA Strategy (qa-lead)

Spawn `qa-lead` via Task to review all in-scope stories and produce a QA strategy.

Prompt the qa-lead to:

• Read each story file
• Classify each story by type: **Logic** / **Integration** / **Visual/Feel** / **UI** / **Config/Data**
• Identify which stories require automated test evidence vs. manual QA
• Flag any stories with missing acceptance criteria or missing test evidence that would block QA
• Estimate manual QA effort (number of test sessions needed)
• **Before assessing smoke status, check for an existing smoke check report**: Glob `production/qa/smoke-*.md` and read the most recently modified file (if found). If a report exists, use its verdict and findings directly — do not re-interview the user. If no report exists, note: "No prior smoke check report found — run `/smoke-check sprint` before proceeding." and set smoke check status to UNKNOWN (treat as PASS WITH WARNINGS for the purpose of continuing). Produce a smoke check verdict: **PASS** / **PASS WITH WARNINGS [list]** / **FAIL [list of failures]** / **UNKNOWN (no report found)**
• Produce a strategy summary table and smoke check result:

| Story | Type | Automated Required | Manual Required | Blocker? | |-------|------|--------------------|-----------------|----------|

**Smoke Check**: [PASS / PASS WITH WARNINGS / FAIL / UNKNOWN] — [source: `production/qa/smoke-[date].md` or "no report found"] — [details if not PASS]

If the smoke check result is **FAIL**, the qa-lead must list the failures prominently. QA cannot proceed past the strategy phase with a failed smoke check.

Present the qa-lead's full strategy to the user, then use `AskUserQuestion`:

question: "QA Strategy Review"
options:
  - "Looks good — proceed to test plan"
  - "Adjust story types before proceeding"
  - "Skip blocked stories and proceed with the rest"
  - "Smoke check failed — fix issues and re-run /team-qa"
  - "Cancel — resolve blockers first"

If smoke check **FAIL**: do not proceed to Phase 3. Surface the failures from the smoke check report and stop. The user must fix them, re-run `/smoke-check sprint`, and then re-run `/team-qa`. If smoke check **UNKNOWN**: surface a warning — "No smoke check report found. Recommend running `/smoke-check sprint` before QA. Proceeding with caution." If smoke check **PASS WITH WARNINGS**: note the warnings for the sign-off report and continue. If blockers are present: list them explicitly. The user may choose to skip blocked stories or cancel the cycle.

Phase 3: Test Plan Generation

Using the strategy from Phase 2, produce a structured test plan document.

The test plan should cover:

• **Scope**: sprint/feature name, story count, dates
• **Story Classification Table**: from Phase 2 strategy
• **Automated Test Requirements**: which stories need test files, expected paths in `tests/`
• **Manual QA Scope**: which stories need manual walkthrough and what to validate
• **Out of Scope**: what is explicitly not being tested this cycle and why
• **Entry Criteria**: what must be