What it does
Takes existing test cases for a feature and implements them as executable procedures at the cheapest effective level, then runs them. The generic implementation engine: logic to unit, endpoints to API, UI behavior to component, journeys to E2E. Failures that are real defects are escalated, not masked.
When to use it
You want to write/add and execute tests for a specific feature or story.
Prerequisites
qa.config.yml (run /qa:qa-init first) and a framework (run /qa:scaffold); honors paths.tests_dir, paths.reports_dir, stack.api_spec_path, tooling.* runner toggles, risk_areas, gates.
Output
Tests under paths.tests_dir with run results in paths.reports_dir (29119-3 Test Procedure Specification + Test Execution Log / Results).
Mechanics
How it works
- Read config and resolve runners/paths; if the framework tree is empty, route to /qa:scaffold
- Resolve the target feature from arguments (default to the first risk_areas.critical item if empty)
- Read the basis: OpenAPI endpoints and existing test cases; design first via /qa:test-design if none exist
- Decide coverage by the pyramid and risk tier (unit / API / component / E2E / contract; flag non-functional needs)
- Reuse existing fixtures, page objects, and typed API clients; provision data via /qa:test-data factories
- Write procedures with stable selectors, web-first assertions, no hard waits, each test owning its data
- Execute with the configured runner; fix test defects, escalate real product defects to /qa:triage
Why it works
The theory behind it
Test implementation + execution (CTFL v4.0 §1.4) — the activity that converts the design (cases) into procedures and actually runs them.
CTFL v4.0 §1.4
Example
See it in use
> /qa:implement "guest checkout"✓ Correct when Logic lands at the lowest effective level (API/component) and only the journey is E2E, with web-first assertions.
Related commands
Used by