qa-shift-left
Shift-left QA: 4 skills (acceptance-criteria-extractor, gherkin-scenario-coverage-map, data-contract-extractor, nfr-extractor) and 4 agents (definition-of-done-checker, spec-to-suite-orchestrator, testability-reviewer, threat-model-from-spec).
Install this plugin
/plugin install qa-shift-left@testland-qaPart of role bundles: qa-role-performance, qa-role-leadership
qa-shift-left
Shift-left QA: testability heuristics with the pre-implementation review workflow, NFR extraction from product docs, and STRIDE threat modeling with the from-spec workflow.
DoD authoring/audit lives in the definition-of-done skill in the qa-process plugin. Acceptance-criteria extraction and Gherkin authoring live in gherkin-from-stories (qa-bdd); scenario coverage mapping lives in bdd-step-library-curator (qa-bdd); data-contract extraction lives in data-contract-extractor (qa-data-quality).
Components
| Type | Name | Description |
|---|---|---|
| Skill | spec-testability-heuristics | Judges whether a written requirement can be tested at all: Observable, Decidable, Bounded, with untestable-to-testable rewrite pairs, a BLOCK / REVIEW / OK verdict, and the review workflow for running the rubric at sprint planning or PR review with per-verdict hand-offs. |
| Skill | non-functional-requirement-extractor | Pull threshold-bound NFRs (perf / a11y / security / compatibility / reliability / i18n / observability) from PRDs; flag missing thresholds. |
| Skill | stride-threat-modeling | Enumerates threats against a design using Microsoft STRIDE, each category paired with the security property it violates, a triage score labelled as convention rather than standard, and the from-spec workflow that writes the threat-model document into the repo. |
Install
/plugin marketplace add testland/qa
/plugin install qa-shift-left@testland-qaSkills
non-functional-requirement-extractor
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 gherkin-from-stories (qa-bdd) handles functional requirements.
spec-testability-heuristics
Judges whether a written requirement can be tested at all, by scoring each claim against three heuristics: Observable (a state or output visible from outside the system), Decidable (a deterministic pass/fail against a named oracle), and Bounded (stated inputs, states, and users). Supplies untestable-to-testable rewrite pairs per heuristic, severity assignment, a BLOCK / REVIEW / OK verdict rule, a findings table that pairs every flagged sentence with a concrete replacement, and the review workflow for running the rubric against a story, PRD section, PR description, or spec at sprint planning or PR review, with per-verdict hand-off targets. Scope is testability only: it does not write the tests, rank risk, or judge whether the requirement is correct or complete. Use when a user story, acceptance criterion, PRD section, API contract, or PR description is about to be handed to implementation and someone needs to know which sentences cannot be verified as written.
stride-threat-modeling
Enumerates security threats against a feature specification or design using Microsoft's six STRIDE categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), each paired with the security property it violates. Covers the asset-and-trust-boundary walk that produces threat rows, the threat-row output schema, a likelihood x impact triage rule labelled plainly as practitioner convention rather than standard, a worked example, an anti-pattern catalog, and the from-spec workflow: read the spec, run the walk end to end, and write the threat-model document into the repo, with a no-fabrication rule for asset-free specs. Enumerates threats against a design; it does not scan code, run a penetration test, or audit control compliance. Use when a PRD section, user story, design doc, or architecture sketch touching authentication, user data, payments, file uploads, or an external integration is about to enter implementation and no threat model exists for it yet.