What it does
Generates the test-automation architecture and testware the rest of the toolkit runs on: runner config, folder structure, fixtures, sample specs, plus performance/contract/a11y/security and a CI pipeline per the config's tooling toggles. Produces the scaffold of work products, not finished test cases.
When to use it
First-time setup of test automation in a project, before commands that run tests.
Prerequisites
qa.config.yml (run /qa:qa-init first); honors paths.*, tooling.* toggles, ci.*, gates, risk_areas, stack.*.
Output
Test-automation framework + CI pipeline under paths.tests_dir / paths.reports_dir (29119-3 Test Procedure Specification scaffold + Test Data / Environment Requirements).
Mechanics
How it works
- Guard on qa.config.yml; read paths/tooling/ci/gates/risk_areas/stack and never hardcode
- Skip any capability whose tooling toggle is unset and record it in 'not scaffolded (and why)'
- Scaffold the framework/language core: runner config, folder structure, fixtures, one sample Page Object + E2E + API spec
- Add enabled extras: performance, contract, accessibility, visual, security stubs
- Generate the CI pipeline for ci.platform with a fast PR gate and nightly/pre-release stages
- Enforce quality rules: stable selectors, no hard waits, per-test data via factories, no hardcoded secrets
- Validate: install deps, run the build/type-check, run a framework smoke run of the samples
Why it works
The theory behind it
Test implementation (CTFL v4.0 §1.4, §6; CT-TAE) — you cannot implement or execute tests without the testware architecture (gTAA) first; built from config so it matches the project's actual stack.
CTFL v4.0 §1.4 · §6 · CT-TAE
Example
See it in use
> /qa:scaffold✓ Correct when The runner runs the sample spec and the structure matches the config's tooling and ci settings.