/qa-plan

name: qa-plan
description: "Generate a QA test plan for a sprint or feature. Reads GDDs and story files, classifies stories by test type (Logic/Integration/Visual/UI), and produces a structured test plan covering automated tests required, manual test cases, smoke test scope, and playtest sign-off requirements. Run before sprint begins or when starting a major feature."
argument-hint: "[sprint | feature: system-name | story: path]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
model: sonnet
agent: qa-lead

QA Plan

This skill generates a structured QA plan for a sprint, feature, or individual story. It reads all in-scope story files and their referenced GDDs, classifies each story by test type, and produces a plan that tells developers exactly what to automate, what to verify manually, what the smoke test scope is, and when to bring in a playtester.

Run this before a sprint begins so the team knows upfront what testing work is required. A test plan written after implementation is a post-mortem, not a plan.

**Output:** `production/qa/qa-plan-[sprint-slug]-[date].md`

---

Phase 1: Parse Scope

**Argument:** `$ARGUMENTS` (blank = ask user via AskUserQuestion)

Determine scope from the argument:

• **`sprint`** — read the most recent file in `production/sprints/`, extract

every story file path referenced. If `production/sprint-status.yaml` exists, use it as the primary story list and fall back to the sprint plan for story metadata.

• **`feature: [system-name]`** — glob `production/epics/*/story-*.md`, filter

to stories whose file path or title contains the system name. Also check the epic index file (`EPIC.md`) in that system's directory.

• **`story: [path]`** — validate that the path exists and load that single file.
• **No argument** — use `AskUserQuestion`:
• "What is the scope for this QA plan?"
• Options: "Current sprint", "Specific feature (enter system name)",

"Specific story (enter path)", "Full epic"

After resolving scope, report: "Building QA plan for [N] stories in [scope]."

If a story file path is referenced but the file does not exist, note it as MISSING and continue with the remaining stories. Do not fail the entire plan for one missing file.

---

Phase 2: Load Inputs

For each in-scope story file, read the full file and extract:

• **Story title** and story ID (from filename or header)
• **Story Type** field (if present in the file header — e.g., `Type: Logic`)
• **Acceptance criteria** — the complete numbered/bulleted list
• **Implementation files** — listed under "Files to Create / Modify" or similar
• **Engine notes** — any engine API warnings or version-specific notes
• **GDD reference** — the GDD path(s) cited
• **ADR reference** — the ADR(s) cited
• **Estimate** — hours or story points if present
• **Dependencies** — other stories this one depends on

After reading stories, load supporting context once (not per story):

• `design/gdd/systems-index.md` — to understand system priorities and which

GDDs are approved

• For each unique GDD referenced across all stories: read the

**Acceptance Criteria**, **Formulas**, and **Edge Cases** sections. Do not load the full GDD text. These three sections contain the testable requirements, the math to verify, and the boundary conditions that tests must cover. If an Edge Cases section is absent from the GDD, note it per GDD: "No Edge Cases section found — edge case coverage will be inferred from acceptance criteria only."

• `docs/architecture/control-manifest.md` — scan for forbidden patterns that

automated tests should guard against (if the file exists)

If no GDD is referenced in a story, note it as a gap but do not block the plan. The story will be classified using acceptance criteria alone.

---

Phase 3: Classify Each Story

For each story, assign a Story Type:

• **If the story already has a `Type:` field in its header**: accept it as-is. Do NOT re-classify or validate against the criteria below — the Type was set by lead-programmer at story creation and is authoritative. Record it as-is.
• **If the `Type:` field is missing**: infer the type from the acceptance criteria using the table below, and note in the report that the type was inferred (not declared). Flag this as a gap — the story should have its Type declared explicitly before implementation begins.

| Story Type | Classification Indicators | |---|---| | **Logic** | Acceptance criteria reference calculations, formulas, numerical thresholds, state transitions, AI decisions, data validation, buff/debuff stacking, economy transactions, or any testable computation | | **Integration** | Criteria involve two or more systems interacting, signals or events propagating across system boundaries, save/load round-trips, network sync, or persistence | | **Visual/Feel** | Criteria reference animation behaviour, VFX, shader output, "feels responsive", perceived timing, screen shake, particle effects, audio sync, or visual feedback quality | | **UI** | Criteria reference menus, HUD elements, buttons, screens, dialogue boxes, inventory panels, tooltips, or any player-facing interface element | | **Config/Data** | Changes are limited to balance tuning values, data files, or configuration — no new code logic is involved |

**Mixed stories** (e.g., a story that adds both a formula and a UI display): assign the primary type based on which acceptance criteria carry the highest implementation risk, and note the secondary type. Mixed Logic+Integration or Visual+UI combinations are the most common.

After classifying all stories, produce a classification summary table in conversation before proceeding to Phase 4. This gives the user visibility into how tests will be allocated.

---

Phase 4: Generate Test Plan

Assemble the full QA plan document. Use this structure:

# QA Plan: [Sprint/Feature Name]
**Date**: [date]
**Generated by**: /qa-plan
**Scope**: [N stories across [N systems]]
**Engine**: