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. 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 true before QA can begin. Always include: (1) Smoke check PASS or PASS WITH WARNINGS report exists at production/qa/smoke-*.md, (2) build is stable (no crashes on launch), (3) all Must Have stories have Status: in-progress or done in production/sprint-status.yaml. Add any sprint-specific criteria beyond these.
• Exit Criteria: what constitutes a completed QA cycle (all stories PASS or FAIL with bugs filed)

Ask: "May I write the QA plan to production/qa/qa-plan-[sprint]-[date].md?"

Write only after receiving approval.

Phase 4: Test Case Writing (qa-tester)

Smoke check is performed as part of Phase 2 (QA Strategy). If the smoke check returned FAIL in Phase 2, the cycle was stopped there. This phase only runs when the Phase 2 smoke check was PASS, PASS WITH WARNINGS, or UNKNOWN.

For each story requiring manual QA (Visual/Feel, UI, Integration without automated tests):

Spawn qa-tester via Task for each story (run in parallel where possible), providing:

• The story file path
• The relevant section of the QA plan for that story
• The GDD acceptance criteria for the system being tested (if available)
• Instructions to write detailed test cases covering all acceptance criteria

Each test case set should include:

• Preconditions: game state required before testing begins
• Steps: numbered, unambiguous actions
• Expected Result: what should happen
• Actual Result: field left blank for the tester to fill in
• Pass/Fail: field left blank

Present the test cases to the user for review before execution. Group by story.

Use AskUserQuestion per story group (batched 3-4 at a time):

question: "Test cases ready for [Story Group]. Review before manual QA begins?"
options:
  - "Approved — begin manual QA for these stories"
  - "Revise test cases for [story name]"
  - "Skip manual QA for [story name] — not ready"

Phase 5: Manual QA Execution

Walk through each story in the approved manual QA list.

Batch stories into groups of 3-4 and use AskUserQuestion for each:

question: "Manual QA — [Story Title]\n[brief description of what to test]"
options:
  - "PASS — all acceptance criteria verified"
  - "PASS WITH NOTES — minor issues found (describe after)"
  - "FAIL — criteria not met (describe after)"
  - "BLOCKED — cannot test yet (reason)"

After each FAIL result: use AskUserQuestion to collect the failure description, then spawn qa-tester via Task to write a formal bug report in production/qa/bugs/.

Bug report naming: BUG-[NNN]-[short-slug].md (increment NNN from existing bugs in the directory).

After collecting all results, summarize:

• Stories PASS: [count]
• Stories PASS WITH NOTES: [count]
• Stories FAIL: [count] — bugs filed: [IDs]
• Stories BLOCKED: [count]

Phase 6: QA Sign-Off Report

Spawn qa-lead via Task to produce the sign-off report using all results from Phases 4–6.

The sign-off report format:

## QA Sign-Off Report: [Sprint/Feature]
**Date**: [date]

### Test Coverage Summary
| Story | Type | Auto Test | Manual QA | Result |
|-------|------|-----------|-----------|--------|
| [title] | Logic | PASS | — | PASS |
| [title] | Visual | — | PASS | PASS |

### Bugs Found
| ID | Story | Severity | Status |
|----|-------|----------|--------|
| BUG-001 | [story] | S2 | Open |

### Verdict: APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED

**Conditions** (if any): [list what must be fixed before the build advances]

### Next Step
[guidance based on verdict]

Verdict rules:

• APPROVED: All stories PASS or PASS WITH NOTES; no S1/S2 bugs open
• APPROVED WITH CONDITIONS: S3/S4 bugs open, or PASS WITH NOTES issues documented; no S1/S2 bugs
• NOT APPROVED: Any S1/S2 bugs open; or stories FAIL without documented workaround

Next step guidance by verdict:

• APPROVED: "Build is ready for the next phase. Run /gate-check to validate advancement."
• APPROVED WITH CONDITIONS: "Resolve conditions before advancing. S3/S4 bugs may be deferred to polish."
• NOT APPROVED: "Resolve S1/S2 bugs and re-run /team-qa or targeted manual QA before advancing."

Ask: "May I write this QA sign-off report to production/qa/qa-signoff-[sprint]-[date].md?"

Write only after receiving approval.

Error Recovery Protocol

If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:

1. Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
2. Assess dependencies: Check whether the blocked agent's out

Content truncated.