jaktestowac/quality-gates

Defines, computes, and interprets test and quality metrics: pass rate, flake rate, suite duration, defect escape rate, time to detect, and coverage with its caveats. Use when building a QA dashboard, reporting suite health to stakeholders, or when a coverage percentage or a bug count is being treated as a measure of quality. To track how these readings move between runs or releases, use tracking-quality-trends.

Analyzes diffs, changed files, hotfixes, and release candidates to find which features a change could break, where regression risk spreads, and what must be retested first. Use when scoping retest after a change, reviewing QA impact for a pull request, or building a minimal confidence suite for release validation. For a rule-based mapping from diff tags to the quality checks a pull request needs, use scoping-change-relevance.

Measures the risk that code shipped without anyone understanding it: a teach-back attestation on high-risk changes, a risk band from changed-code complexity, diff size and whether a human explanation accompanied it, and optional AI-authorship provenance. Findings stay advisory by design. Use when an AI-assisted codebase grows faster than the team reads it, when reviews are rubber-stamped, when nobody can explain a module that ships weekly, or when leadership asks how much of the code the team can actually maintain.

Produces an evidence-backed go/no-go recommendation: exit criteria status, open-defect risk profile, coverage against risk, environment parity, rollback readiness, and the residual risk stated plainly. Use when preparing a release sign-off, when someone asks whether a build is ready to ship, or when a decision to release is being made on impressions rather than evidence.

Records human verification - code review, exploratory sessions, UAT, accessibility passes, UX and observability reviews - as dated, attributed attestations in a register, so human-centric practices stay in the quality contract without pretending to be automated checks. Use when recording that a manual pass was done, by whom and when, as sign-off evidence, when a strategy requires verification no tool can prove, when sign-off evidence is scattered across chats and tickets, when a gap matrix needs to distinguish "attested" from "passed", or when an audit asks who verified what and when.

Audits repository-level quality debt (technical, intent, and comprehension) and inventories every silent skip: skipped tests, disabled lint rules, ts-expect-error, continue-on-error, coverage ignores, lowered thresholds, raised retries, and expired waivers. Use when a team wants to know what its CI and quality gates have quietly stopped enforcing, before a quality review, or when taking over a repository. For anti-patterns inside test code itself (selectors, waits, assertions), use the tech-debt-audit command.

Derives which testing practices are MUST, SHOULD, or COULD for this project from its risk profile, team maturity, and product surfaces, then reports a PRESENT/PARTIAL/MISSING/WAIVED gap matrix and an ordered remediation plan. Use when a team asks what testing it should be doing, when setting up quality gates for a new or inherited repository, or when the contract must be rebuilt after a change in risk. To audit what existing gates have stopped enforcing, use the audit-quality-debt command.

Derives a project-specific quality contract from three axes - risk profile, team maturity, and product surface - labelling each testing practice MUST, SHOULD, or COULD, then produces a PRESENT/PARTIAL/MISSING/WAIVED gap matrix with an ordered remediation plan. Use when a project has no agreed testing strategy, when a team argues about which practices are mandatory, when onboarding a legacy or inherited repository, when a quality strategy document has to be derived from evidence instead of opinion, or when someone asks "what testing should we actually be doing here".

Generates the CI workflow that enforces a quality contract: layered jobs from fast local hooks to release gates, per-practice steps for JS/TS toolchains, diff-scoped checks, sticky PR reporting, required checks that block a merge, and a severity policy deciding what fails the build. Use when quality practices are agreed but not enforced, when deciding which checks block a merge, when CI runs everything on every commit, when a gate reports green while the check it runs cannot fail, or when a per-change gate needs to post findings on the pull request.

Turns "we will skip this check for now" into a dated, attributed, expiring waiver with a stated reason and owner, inventories the silent skips already hiding in a repo - skipped tests, disabled lint rules, ts-expect-error, continue-on-error, lowered thresholds, coverage ignores - and reports expired waivers as findings. Use when a team wants to bypass a quality gate, when skip lists and quarantined tests accumulate without owners, when an audit asks why a check is off, or when a repo needs to know what it has quietly stopped enforcing.

Finds the high-risk surface in a change range, checks whether a rationale already exists in commit trailers, ADRs, or a module intent register, and drafts an Intent trailer for the author to confirm (why now, what constrained the shape, what was rejected). Use when a change touches auth, schemas, public APIs, or removed guards and its reason is not written down, or before merging a change someone will need to understand later. For a full scope, coverage, and intent gate on a diff, use the scope-change-gate command.

Requires an externalised rationale for high-risk changes - new public exports, new endpoints, auth edits, migrations, removed guards - recorded as an Intent commit trailer, an ADR reference, or a module intent register, and reports high-risk changes that carry none. Use when agent-generated or AI-assisted changes ship without a recorded why, when reviewers cannot tell what a diff was for, when a codebase is losing its decision history, or when setting up an intent gate alongside test and coverage gates.

Tags a diff by file and hunk, resolves which quality practices the change makes relevant, verifies coverage of changed lines and the recorded intent, and returns severity-ranked findings with remediation briefs. Use when a pull request is about to merge, when deciding what a change needs tested, or when a diff touches auth, schemas, migrations, or removes tests or guards. For only drafting the missing rationale, use the record-change-intent command; for a manual retest pack, use the regression-scope command.

Classifies a diff into file tags and hunk tags - new public export, new endpoint, modified auth, SQL string, migration, added dependency, touched prompt - then maps each tag to the quality practices it makes relevant, producing a defensible per-change check scope instead of running everything or guessing. Use when deciding what to test for a specific pull request, when a full regression run is too slow to gate on, when a pre-push or PR gate needs a scope someone can argue with, or when asked "which checks does this change actually need". For reasoning about blast radius and which features to retest, use analyzing-regression-scope.

Analyzes technical debt in codebases, test suites, architecture, dependencies, and delivery workflows from observable signals, and produces a prioritized register and remediation roadmap with severity, risk, effort, and ROI. Use when auditing repository health, explaining slow delivery or flaky tests, planning refactoring, or deciding what to fix now versus defer. For skipped checks and expired waivers, use governing-quality-waivers; for code nobody on the team understands, use assessing-comprehension-debt.

Turns point-in-time quality readings into a trend: archives each run, compares it with the previous one, and reports per metric whether it is getting better or worse - practices newly present or regressed, coverage, flake rate, expiring waivers, eval scores - using limit/current/goal framing. Use when quality reporting is a series of disconnected snapshots, when a team needs to show whether a number went up or down over a quarter, between runs, or since the last release, when a number such as coverage is quoted with no baseline to compare against, or when a regression in the quality system itself should be visible. For what each metric means and how it misleads, use analyzing-quality-metrics.

Verifies that the lines and branches a change actually touched are executed by tests, using LCOV or Cobertura diff coverage instead of whole-repo percentages, and escalates uncovered high-risk changes into a blocking finding. Use when a pull request needs a coverage gate that unrelated tests cannot satisfy, when total coverage looks healthy but the diff is untested, when wiring diff coverage into CI, or when someone claims a change is covered because the suite is green.