Claude-Code-Game-Studios/.claude/skills/team-qa/SKILL.md

name, description, argument-hint, user-invocable, allowed-tools, agent

name	description	argument-hint	user-invocable	allowed-tools	agent
team-qa	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.	[sprint | feature: system-name]	true	Read, Glob, Grep, Write, Task	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.

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): read all story files in production/sprints/[sprint]/
   • 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)
• Produce a strategy summary table:

  Story	Type	Automated Required	Manual Required	Blocker?

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"
  - "Cancel — resolve blockers first"

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 (smoke check pass, build stable)
• 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: Smoke Check Gate

Before any manual QA begins, run the smoke check.

Spawn qa-lead via Task with instructions to:

• Review the tests/smoke/ directory for the current smoke test list
• Check whether each smoke test scenario can be verified given the current build
• Produce a smoke check result: PASS / PASS WITH WARNINGS / FAIL

Report the result to the user:

• PASS: "Smoke check passed. Proceeding to test case writing."
• PASS WITH WARNINGS: "Smoke check passed with warnings: [list issues]. These are non-blocking. Proceeding — note these for the sign-off report."
• FAIL: "Smoke check failed. QA cannot begin until these issues are resolved: [list failures] Fix them and re-run /smoke-check, or re-run /team-qa once resolved."

On FAIL: stop the cycle and surface the list of failures. Do not proceed.

Phase 5: Test Case Writing (qa-tester)

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 6: 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 7: 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]
**QA Lead sign-off**: [pending]

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

Output

A summary covering: stories in scope, smoke check result, manual QA results, bugs filed (with IDs and severities), and the final APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED verdict.