svallejo-dev/qa

Turns a spec or a ticket into acceptance criteria verifiable from the outside, each with its oracle; applies the usage-oracle rule (if someone else consumes the result, the consumer decides), makes implicit criteria explicit and runs a criteria premortem. Use it when the user asks for "acceptance criteria", "definition of done for the feature", or before designing QA scenarios.

Shared base of the QA domain: role model (dev, QA, executor, human), environment ladder, formats for criteria, scenarios and findings, and the deterministic scripts (integrity seal, traceability, mutants). Use it when another qa-* skill references it, or when the user asks how the QA model works, what the seal guarantees or how criteria are traced to tests.

Sets up the qa plugin in a repo: mode (solo or duo), information barrier, where the acceptance tests live, which rungs of the ladder exist and which script runs each one, the black-box check and the mutant budget. Writes docs/agents/qa.md. Use it only when the user explicitly asks for it.

Implements the approved scenarios as executable tests, with existing tools (Gherkin with godog, Hurl, Testcontainers, Toxiproxy, WireMock, Pact, Schemathesis, Playwright) and AI-generated plumbing; third-party learning tests first, then the scenarios, and it checks that each test fails for the right reason and is deterministic before sealing. Use it when the user asks to "automate the tests", "implement the scenarios", for "acceptance tests", "e2e tests", "learning tests" or after qa-test-design.

Designs a feature's test scenarios from approved criteria and the handoff contract, with parallel subagents per technique (partitions and boundaries, decision tables and states, third parties and usage oracle, failures and environment, error guessing and abuse); assigns each scenario to a rung and traces it to its criteria. Use it when the user asks to "design tests", for "test scenarios", "test cases", a "test plan", or after approving criteria with qa-acceptance-criteria.

Tests the acceptance suite by injecting plausible bugs (mutants) into the diff's code, in temporary worktrees that never touch the repo, and reports which bugs survive; each survivor is a concrete gap in the scenarios. Use it when the user asks "are the tests any good?", "does the suite have teeth?", asks for "mutation testing", "bug injection" or "testing the tests", and as a gate of the full cadence (mandatory in solo mode).

QA tools radar (adopt, trial, assess, hold) and a guide to choosing the tool for each scenario by rung, by the artifact the human reviews and by how deterministic the runner is. Use it when the user asks "which tool do I use for…?", "Karate or Hurl?", "how do I test X?", or when qa-test-automation has to choose a tool for a scenario.

Runs a feature's verification by cadence (per slice, full or post-deploy) with the declared scripts, goes through deterministic gates (seal against the base branch, black box, fresh run, traceability, stability, contracts, mutants), classifies each failure (code, configuration, spec, test or environment), pushes it down the ladder and issues findings with evidence. It never certifies: it delivers evidence for a human to decide. Use it when the user asks to "verify", "run the acceptance tests", "QA the feature", "is it ready?", or when closing a ticket or before a PR.