What it does
Combines qa.config.yml with a release ID and feature list into a complete Test Plan: features in/out tagged by risk tier, in-scope test types limited to enabled tooling, entry/exit criteria using the exact gates thresholds, sample Given/When/Then cases per feature, a risk register, RACI, and a residual-risk section. It links to the Strategy rather than repeating it.
When to use it
When planning a specific release or sprint. Derives from the Organizational Test Strategy.
Prerequisites
qa.config.yml (run /qa:qa-init first) — paths, tooling, gates, risk_areas, team, test_data, process.sprint_length_weeks. Plus the release ID and features as args.
Output
ISO/IEC/IEEE 29119-3 Test Plan -> <paths.docs_dir>/TEST-PLAN-<release-id>.md.
Mechanics
How it works
- Parse release ID (first token) and feature list from $ARGUMENTS; ask if empty
- Config guard: stop and route to /qa:qa-init if missing
- Load the plan template
- Build scope with features tagged by risk tier and only enabled test types
- Set entry/exit criteria from the exact gates thresholds
- Add sample cases (happy/negative/authz/non-functional) per feature
- Add risk register, RACI from team, residual-risk section; write TEST-PLAN-<id>.md
Why it works
The theory behind it
The Test Plan work product (CTFL §5.1; ISO/IEC/IEEE 29119-3). A plan is risk- and context-driven, so it consumes the risk register and config rather than a fixed template; every feature traces basis -> condition -> case and gates carry verbatim into exit criteria, keeping the chain auditable.
CTFL v4.0 §5.1 · ISO/IEC/IEEE 29119-3
Example
See it in use
> /qa:create-plan R2.4 "guest checkout, saved cards"✓ Correct when Scope = the two features, exit criteria = the gates (e.g. ≥98% pass, block on S1/S2), and it cites the release's risk areas.