What it does
Detects project signals (package manifest, API spec, CI files, test dirs), asks you for what it cannot infer, validates against the template schema, then writes qa.config.yml at the repo root. It seeds the context — stack, tooling toggles, CI, gates, risk areas — that every later planning artifact consumes.
When to use it
First thing in any new project; re-run to refresh the config. Most other commands degrade to 'create qa.config.yml first' without it.
Prerequisites
Nothing — it creates the config. Reads detected signals (package.json, openapi/swagger, CI files, test dirs).
Output
Project test-context configuration (29119-3 context input that feeds the Organizational Test Strategy and Test Plan) -> ./qa.config.yml.
Mechanics
How it works
- Detect project signals from manifests, API spec, CI files, test dirs
- Pre-fill stack/CI/spec path/test dir from those signals
- Interview the user (grouped questions) for anything not inferable
- Run pre-write validation: schema match, valid YAML, no invented values, mandatory minimum
- Emit a readiness checklist (populated vs TBD per section)
- Write ./qa.config.yml and a structured summary with counts and next steps
Why it works
The theory behind it
Realizes the first step of the ISTQB test-planning activity — establishing project context (CTFL v4.0 §1.4). The config is the ISO/IEC/IEEE 29119-3 context input every downstream work product reads, which turns Principle 6 (testing is context-dependent) into an engineering mechanism: identical commands behave per-project because only the config differs.
CTFL v4.0 §1.4 · §5.1
Example
See it in use
> /qa:qa-init✓ Correct when qa.config.yml exists at repo root with your real project, stack, tooling, gates, and risk_areas filled in (not generic defaults).
Related commands