/team-qa

name: team-qa
description: "Orchestrate the QA team through a full testing cycle — qa-lead strategy and test plan, qa-tester case writing, execution, sign-off."
argument-hint: "[sprint | feature: system-name] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash "*/.claude/skills/team-qa/../../hooks/yaml-helper.sh" resolve_config *)
model: sonnet

Team QA

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. In `collaborative` mode, the user must approve before moving to the next phase. In `guided` mode the pipeline advances automatically unless a phase is BLOCKED; in `autonomous` mode it runs end to end, recording each phase outcome via `log_decision`. Decisions in `automation_always_ask` categories (`is_always_ask_category` helper) always prompt regardless of mode. See `.claude/docs/automation-modes.md`.

Phase 0: Resolve Config

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,qa.level`

Resolved above — use as-is; `--review` overrides `review_mode`. No block → defaults in `.claude/docs/config-resolution.md`.

`qa.level` decides what a Logic, Integration or Config/Data story's evidence is: its automated test at `standard` and `full`; at `minimal`, where tests are waived (`.claude/docs/coding-standards.md`), the acceptance-criteria walk in Phase 5 — a story without a test is then WAIVED, not missing its evidence. The UI and Visual/Feel screenshots are required at every level.

`review_mode` sets director-gate depth, and this pipeline has no director gate: no phase below spawns CD-, TD-, PR- or AD-PHASE-GATE, at any `review_mode`. Its phase gates are the pipeline's own decision points (defined under `team.size` below), and the agents that work at them are team members, not director gates.

`automation` drives the Decision Points note above. See the Decision Points note above and `.claude/docs/automation-modes.md` for how each mode changes pipeline behavior.

**`team.size`**: which agents are active (orthogonal to review_mode gate-depth and workflow docs).

• **`individual`** (default): `qa-tester` only; `qa-lead` invoked at phase gates only.
• **`small`**: `qa-lead` + `qa-tester` pipeline (as documented).
• **`studio`**: `qa-lead` + per-story `qa-tester` spawn + sign-off.

A non-core agent needed at `individual` routes through the nearest active core agent with an informational note. **"Phase gate" means any phase that ends in an `AskUserQuestion` decision point this pipeline itself lists** — a transition under Decision Points above, or a **Gate** step written into the pipeline below — **whatever the `automation` mode**: in `guided` or `autonomous`, where that question is skipped or logged, the phase is still a gate. Not every phase is one. Apply the test literally: if the phase below lists no decision point, it is not a gate, and an agent restricted to "phase gates only" is not spawned for it. This active-set scoping applies throughout the pipeline below: any phase that names an agent outside the active set routes through the nearest core agent rather than spawning it.

**Announce the active set before Phase 1 — never let the collapse be silent.** Before spawning anything, state in one line which agents this run will actually spawn, and which the pipeline below names but will **not** spawn at the resolved `team.size`. For example:

> `Active set (team.size: <resolved>): <the agents listed for that size above>.` > `Not spawned this run: <every other agent this pipeline names> — consulted` > `through <nearest active core agent>. Raise team.size (or modes.rigor) to widen.`

Fill it from the `team.size` list directly above and the agents this file's own pipeline names — not from an example. Both sets differ per orchestrator. An agent the resolved size spawns only at phase gates (`qa-lead` at `individual`) goes in the active set with that qualifier — it is spawned, not consulted through another agent.

The pipeline below reads as a multi-agent fan-out and at the shipped default it is one or two agents — `team-release` names ten and runs one, `team-narrative` names six across five phases and runs `writer` alone. **The collapse is correct**: `team.size` is rigor-fronted and the narrow default is the token lever. Without saying so, a reader cannot distinguish a correctly-collapsed run from a broken pipeline, and the per-agent "routes through the nearest core agent with an informational note" rule above fires at routing time and never states the shape of the run as a whole.

This is the same rule as the skipped-check reporting elsewhere in this file: **a constraint that is enforced but never surfaced is indistinguishable, to the person reading the output, from one that was never enforced.**

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 `Agent` 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

**Brief each agent — do not dump context.** Read the shared inputs **once** and pass a distilled brief inline: the lines each agent actually needs, never a file path for a document you have already read (an agent handed a path re-reads the whole file). Pass a path only for a document you have not read and only that agent needs.

**End every agent prompt with a return contract:** "Write your full output to `[path]` — that named path is your write authorisation under the bounded exce