qa-shift-left

Adversarial reviewer that validates a user story or PR against a configurable Definition of Done checklist before it's marked ready for development (or ready for release). Reads the team's `docs/definition-of-done.md` (or an inline DoD), checks every item against the story / PR artifacts, and rejects with a per-item rationale on any miss. Use proactively at sprint planning (story → ready) and at sprint review (PR → done).

Action-taking orchestrator that chains the qa-shift-left components - testability-reviewer → acceptance-criteria-extractor → nfr-extractor → threat-model-from-spec (when applicable) → data-contract-extractor (when applicable) → bug-repro-builder for initial stubs - to turn a single feature spec into a complete planning-and-test artifact set in one pass. Use when a story enters dev-ready status and the team wants the full shift-left workflow run end-to-end without manually invoking each component.

Reviews a feature spec, PR description, or user story for testability - flags missing acceptance criteria, ambiguous edge cases, untestable assertions, and undefined preconditions BEFORE the team starts implementing. Returns a prioritized findings table with the specific text that needs clarification and a suggested rewrite. Use proactively during sprint planning or PR review, before code is written.

Builder agent that takes a feature specification (PRD section, user story, design doc, or architecture sketch) and produces a STRIDE-based threat model - one row per identified threat, classified into Spoofing / Tampering / Repudiation / Information Disclosure / Denial of Service / Elevation of Privilege, with the affected asset, the attack vector, and a recommended mitigation. Use proactively for any feature touching authentication, user data, payments, file uploads, or external integrations.

Reads a user story, PRD section, or feature spec and emits well-formed acceptance criteria as Given/When/Then steps in Gherkin (Feature/Scenario file format) or as a numbered plain-text list. Identifies missing-precondition gaps and proposes Background blocks for shared context. Use after a story is testability-confirmed and before implementation begins.

Parses new Gherkin scenarios produced by acceptance-criteria-extractor, fingerprints each scenario by its Given/When/Then step sequence, diffs the fingerprints against existing step-definition usage in the live suite, and emits a coverage/duplicate map showing which new scenarios are already covered, which overlap partially, and which are genuine gaps. Use when acceptance criteria have been converted to .feature files and before any new automated tests are authored.

Reads a data-product spec (data PRD, dataset README, lineage doc) and emits a structured data contract - schema (columns + types + nullability + PII flags), freshness SLA, volume bounds, distribution invariants, and ownership. The contract is consumable by the qa-data-quality plugin's dbt-testing / great-expectations / soda-checks skills as their assertion baseline. Use when scoping a new data product or formalizing assertions on an existing one.

Reads a PRD, design doc, or product brief and pulls out the non-functional requirements (performance, accessibility, security, internationalization, reliability, observability) as concrete, threshold-bound, testable assertions. Maps every NFR to its measurement source (Lighthouse, axe, OWASP ASVS, WCAG criterion, etc.) so the test suite knows what to assert against. Use after acceptance-criteria-extractor handles functional requirements.