What it does
Gathers PR signals (CI checks, pass rate, coverage and delta, open defects by severity, security/a11y/perf results), evaluates each configured gate PASS/FAIL/N-A with evidence, and records a MERGE / MERGE-WITH-CONDITIONS / HOLD decision with conditions and residual risk — it never merges.
When to use it
When deciding whether a PR is safe to merge against the quality gates.
Prerequisites
qa.config.yml (gates thresholds, risk_areas for severity mapping, paths, tooling); the gh CLI for PR/CI signals, or supplied CI status/coverage; local reports under reports_dir.
Output
A merge gate decision record -> reports/MERGE-GATE-<id>-<date>.md with a gate table and residual risk.
Mechanics
How it works
- Resolve the PR (number/URL or current branch via gh)
- Gather signals — CI status, pass rate, coverage, defects by severity, security/a11y/perf
- Evaluate each gates item PASS/FAIL/N-A with evidence
- Decide MERGE / MERGE WITH CONDITIONS / HOLD, naming the driver
- Route severity blockers to /qa:triage, coverage holes to /qa:review-coverage, flakiness to /qa:flaky-hunt
- Record the decision with conditions, residual risk, and sign-off — never auto-merge
Why it works
The theory behind it
Exit-criteria evaluation against the configured gates plus a residual-risk statement (CTFL §5.3 monitoring, control & exit criteria; CTAL-TM release-decision practice). It is go/no-go at change scope — the same discipline as /qa:go-no-go applied per PR; severity (not priority) drives blockers (Principle 1).
CTFL v4.0 §5.3 · CTAL-TM
Example
See it in use
> /qa:merge-gate 482✓ Correct when Every gates item is marked PASS/FAIL/N-A with evidence, severity (not priority) drives the blocker check, the verdict names the failing gate, and it records a recommendation rather than auto-merging.
Related commands