qa-process

Builder/scaffolder agent that runs a configurable gate suite before a release - reads `release-readiness.yml` (which defines the gates: smoke passed, coverage met, no open critical bugs, threat-model approved, RBAC change reviewed, etc.), executes each gate, aggregates the verdicts, and emits a go / no-go decision with per-gate evidence. Use as the precursor to `release-engineer`''''s runbook execution - release-readiness verifies "should we even start the runbook?" while release-engineer is "now we''''re starting; conduct the canary + rollout.

Adversarial agent that audits a risk register (product or release) for assessment quality. Checks: every risk has both impact AND likelihood scored independently (not auto-equated), scores are justified (not gut-feel), all 4 ISO 31000 strategies considered before Accept is chosen, mitigations link to test coverage (via risk-coverage-mapper) or to a documented decision (via risk-acceptance-decision-author), critical risks (score ≥15) have escalation evidence, and the register has been reviewed within its cadence (quarterly for product, weekly for project). Use as a hygiene gate before release planning or quarterly review.

Action-taking strategic planner - given a feature scope or change initiative + the risk matrix, applies risk-based prioritization to choose what to test deeply, what to skip, and where to allocate manual / automated / chaos / load test investment. Distinct from `risk-based-test-selector` (per-PR tactical) - this is per-feature / per-quarter strategic. Emits a test plan with test types per risk class, owner assignments, and effort estimates.

Action-taking agent that picks the subset of tests to run for a specific change set, weighted by the risk matrix - reads the PR's diff, intersects the changed files with risks in the matrix, scopes the test run to (a) tests covering high-risk areas + (b) tests covering changed files, and emits the test selection. Differs from `regression-suite-selector` (which uses coverage maps) - this uses risk weights from the matrix per `risk-matrix`.

Read-only specialist that ingests an existing risk matrix (per `risk-matrix`) plus historical CI + defect data and recommends data-informed adjustments to risk scores - flags entries where observed defect density / failure rate / escape rate diverges from the matrix's likelihood × impact, suggests new entries for areas with high observed defect density that are not in the matrix, and reports every recommendation with the underlying data citation. Refuses to modify the matrix; the team reviews and applies. Distinct from `risk-based-test-selector` (deterministic test selection from a fixed matrix) and from `risk-based-test-planner` (strategic plan from a fixed matrix). Use as a quarterly / per-release calibration of the matrix against actual outcomes.

Pure-reference + checklist-generator for the team's Definition of Done (DoD) - explains the Scrum Guide's DoD definition ("a formal description of the state of the Increment when it meets the quality measures required for the product"), proposes a starter DoD with the 7-10 lines most teams need (code reviewed, unit tests, docs, AC met, deployed to staging, smoke passed, no a11y regressions, telemetry wired, observability in place), and emits a per-PR checklist `quality-coach` enforces. Use when the team doesn't have a DoD or wants to revise theirs.

Build-an-X workflow that caps the E2E suite size by computing flakiness ROI per test - for each E2E test, computes (regressions caught × value) ÷ (runtime × flake rate × maintenance cost), ranks all tests by ROI, identifies the bottom decile (low ROI = high cost / low signal), and recommends specific tests to retire / move to lower layer / fix flake. Use quarterly to keep E2E count from growing past the team's maintenance capacity.

Build-an-X workflow that produces a test strategy document for a project / release / feature - covers scope, in/out, test types per layer (unit / integration / contract / E2E / perf / security / a11y), risk-based prioritization mapping (per `risk-matrix`), tooling stack, environments, exit criteria, ownership. Use as the artifact stakeholders sign off on before significant test investment, and the reference engineering teams come back to when scope / quality questions arise.

Pure reference catalog for picking a test automation framework - covers Playwright / Cypress / Selenium / WebdriverIO / Appium / Espresso / XCUITest / RestAssured / Karate / k6 / Locust with side-by-side tradeoffs on speed, cross-browser, mobile, parallelisation, language support, ecosystem maturity, CI integration; a decision tree for matching project NFRs to framework choice; and reference directory / fixture / CI layouts for the chosen stack. Distinct from the per-framework skills (`playwright-testing`, `cypress-testing`, etc.) which document configuration once a framework is chosen - this skill is the **upstream selection step**. Distinct from `test-pyramid-balancer` (which tunes the layer mix for an existing suite). Use when starting a new test-automation suite from scratch, before installing any tool.

Reference catalog of the four canonical heuristic test-design models - Bach's Heuristic Test Strategy Model (HTSM) with SFDPOT product elements, Whittaker's 'How to Break Software' attack patterns, Bolton's FEW HICCUPPS consistency oracles, and the ISO/IEC 25010 quality characteristics - for use when the tester has no user story, no acceptance criteria, and no documentation. Distinct from `test-case-ideation-from-story` (which works from a written story) and from `exploratory-charter-author` (which produces session charters, not case sets). Use as the reference layer that `test-case-from-live-feature` and `exploratory-charter-author` cite when generating coverage from zero documented input.