What it does
Commits a staged change only after fast checks confirm it: runs the affected tests/lint/static review, writes a Conventional Commits message linking the change to its test basis, refuses to commit an unverified or failing change, and never pushes.
When to use it
When committing test or feature work and you want it verified and traceable before it lands.
Prerequisites
qa.config.yml (tooling for the verification runner, stack); a staged change in the working tree.
Output
A verified Git commit (hash + Conventional Commits message); nothing is pushed.
Mechanics
How it works
- Read the staged diff; classify the Conventional Commits type and scope
- Run affected tests / lint / static-review (resolved from tooling) as a gate
- Commit only if the checks pass
- Route a real product defect to /qa:triage instead of committing
- Write a message tracing to the requirement/defect (Refs:/Fixes:)
- Commit; never push, amend published history, or force
Why it works
The theory behind it
Confirmation testing before integrating a change plus traceability (CTFL §1.4; §1.4.4; Glossary). Verifying before committing enacts Principle 1 — never integrate an unverified or defect-masking change; the traceable message keeps the basis-to-change chain intact.
CTFL v4.0 §1.4 · §1.4.4 · Glossary (confirmation testing)
Example
See it in use
> /qa:commit "fix: expired-coupon 500"✓ Correct when It runs the affected tests/lint first, commits only if green, writes a Conventional Commits message tracing to the requirement/defect (Fixes: DEF-…), and never pushes — a failing change routes to triage instead of being committed.
Related commands
Used by