Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →donchitos/qa-plan
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.
Passed 12 of 18 test cases with the skill, and 3 of 18 without it.
and 17 more in the full report
13 fixed2 passed either way6 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/2/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
Story `production/epics/magic/story-003.md` lacks a `Type:` header. Its criteria involve both mana calculation math and cross-system network event propagation across combat and save systems. When ambiguous between Logic and Integration, which type must be selected?
| Checked | Without skill | With skill |
|---|---|---|
| The response classifies the ambiguous story as Integration. | Passed | Passed |
| The response notes that Integration stories require both unit and integration tests. | Missed | Passed |
The instructions your model reads when the skill loads.
!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,qa.level,system_overrides
Resolved above — use as-is. No block → defaults in
.claude/docs/config-resolution.md.
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
Every AskUserQuestion call follows .claude/docs/automation-modes.md
(collaborative asks always · guided major-only · autonomous logs and proceeds;
automation_always_ask categories always prompt).
Workflow tier: resolve per the GDD's system as each is read (per
.claude/docs/workflow-modes.md): workflow_overrides.system_overrides.<system>
if the block lists one, else the project value. It sets how many GDD sections
the test plan is mined from — see Phase 2.
qa.level: at minimal, produce only a minimal smoke
plan — drop the automated-test-required rows and the test-file DoD; at standard,
a full plan per story type; at full, also add per-system coverage targets.
Distinct axis from workflow (which sets how many GDD sections are mined).
No level drops the Visual/Feel and UI screenshot rows — tests are waived at
minimal, the look is not (.claude/docs/coding-standards.md).
test cases passed, vs 3 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.