QAIA-Project
OrganizationAgentic QA for Claude Code - turn a user story into an ISTQB-grounded Gherkin test book and runnable Playwright tests. Markdown skills, no API key, nothing that auto-executes.
Categories
Indexed Skills (43)
requirement-ambiguity-hunt
Find what a user story does not say before writing a single test - undefined terms, unstated clocks, cross-rule contradictions, missing error paths - and turn each into a numbered question for the product owner instead of a silent guess baked into an assertion.
accessibility-audit
axe-core through Playwright on every key screen, failing on critical and serious only, plus the seven manual checks a DOM scanner structurally cannot perform. Use when a WCAG 2.1 AA claim has to survive someone checking it — automated tooling reaches about a third of the success criteria, and the other two thirds are what actually stops a disabled user.
generated-test-self-review
Re-scan a test you just generated before writing it to disk, against nine defect classes - four that make an assertion unable to fail, and five measured on real generated suites that a static reader accepts because every assertion is real.
istqb-technique-selection
Pick the test design technique each acceptance criterion actually calls for, write the one-sentence reason next to it, then derive the concrete conditions to cover. Use when coverage has to be defensible to someone else — including the refusal paths a percentage-based negative target lets you skip.
performance-budget-check
Set a latency budget and say where the number came from, prove a limited resource cannot be oversold under concurrency, and pick the CT-PT test type the question actually calls for. Use when a performance number needs a justification — spike and soak change what green means and are not load with different numbers. Self-hosted targets only.
visual-regression-baselines
Playwright screenshot tests scoped to stable containers with an explicitly chosen tolerance, dynamic content frozen rather than masked, and a first run treated as baseline creation. Use when screenshot tests need to survive a second week — an unstated tolerance and a first run counted as green are why most visual suites get deleted.
hello
Verify a QAIA installation and list the skills, journey steps and plugins available in this session. Use when QAIA has just been installed, when a skill does not seem to trigger, when someone asks what QAIA can do or where to start, or as a first smoke check before running a journey.
feedback
Capture the tester's corrections on a generated test book, store them as examples, and propose validated promotion of recurring corrections into knowledge-base rules so future generations improve. Use after someone has reviewed or reworked generated tests, when the same correction keeps coming back run after run, or when asked to make QAIA learn a project's own conventions instead of repeating the same mistake. Final step of the QAIA journey.
need-understanding
Analyze a validated user story extraction - reformulate the need, detect ambiguities, contradictions and missing rules, ask the user targeted questions, and record answers or explicit assumptions. Use whenever a specification looks incomplete, contradictory or open to interpretation, when someone asks what to clarify with the product owner before testing, or before committing to test design on a story nobody has challenged yet. Third step of the QAIA journey.
oracle-generate
Use known standards as test oracles to generate grounded test cases and their correct expected results - Luhn for card numbers, ISO 8601 dates, HTTP status codes, RFC 5322 email, ISO 4217 currencies, IBAN - plus an opt-in project oracle that derives endpoint conditions and expected statuses from a user-designated OpenAPI/Swagger or JSON Schema file. Feeds istqb-design and testbook-generate. Bounded, provenance-tagged. Use when a US touches a standardized domain or has an API contract.
prioritize
Risk-based prioritization of derived test conditions - the skill proposes probability x impact scores, the human arbitrates. Use when there is more to test than time allows, when someone asks what to test first or what can be dropped, or before generating a test book so generation covers the right conditions. Fifth step of the QAIA journey, before test book generation.
qaia-help
Inspect the project's QAIA state and tell the user exactly where they are in the journey and what the next step is. Use when the user asks what to do next, seems lost, or at the end of any QAIA skill.
us-ingest
Ingest a user story or requirement document (pasted text, file, URL, or a Jira issue via export or a bounded MCP fetch) and have the user validate the captured source. First step of the QAIA journey. Use when the user wants to start test design from a US, spec, ticket or document.
us-review
Verify that an ingested user story was correctly extracted - restructure it (story, acceptance criteria, business rules, open points) and have the user confirm or fix the extraction. Use right after ingesting a US, and whenever someone asks whether a specification was read faithfully, whether acceptance criteria were missed, or wants to check an extraction before designing tests on top of it. Second step of the QAIA journey, after us-ingest.
a11y-audit
Generate and run accessibility tests (axe-core via Playwright, WCAG 2 A/AA) against a running app, plus the keyboard/focus/contrast checks no scanner can perform, reporting violations by severity. Use when a test book or an app needs accessibility coverage, when an accessibility regulation applies (EAA, EN 301 549, RGAA, Section 508) — the oracle is WCAG 2.1 A/AA in every case, and no run here is a compliance verdict; see references/regulations.md — or when a user asks whether a screen is accessible.
flaky-detect
Detect tests whose pass/fail verdict varies across repeated runs of unchanged code (flaky tests), from the JUnit XML / Cucumber JSON that run-report already produces. Flags with evidence only - never retries, quarantines, or fixes automatically. Use after collecting 3+ runs of the same suite.
locator-repair
Diagnose a Playwright test failing on a broken locator (getByRole/getByTestId not found or timed out) and propose a candidate fix as a reviewable diff with evidence-based justification -- never applied automatically. Use after a test fails with a locator-not-found/timeout error, ideally with the current DOM or ARIA snapshot available.
run-report
Produce an execution report from a Playwright run in the formats the QA profession consumes - JUnit XML, Cucumber JSON, and a self-contained HTML summary - with requirement traceability. Use after running an automated suite, when a CI dashboard or an ALM needs the results, or when someone asks what the last run actually produced.
traffic-replay
Ingest a user-provided HAR file (or equivalent captured HTTP traffic export) and derive non-regression test conditions -- observed status, response shape, significant headers, timing -- from real request/response pairs, with mandatory PII/secret masking before any write. Never captures live traffic, never runs a proxy, never sends a network request itself. Use when the user has a HAR export and wants what actually happened turned into regression conditions, not a coverage test book.
usability-heuristic-review
Review a running app's screens against Nielsen's 10 usability heuristics (CT-UT) via a structured heuristic evaluation and a cognitive walkthrough of one key task, reporting violations by severity. Use for usability coverage. Self-hosted targets only.
visual-check
Generate and run visual regression tests (Playwright screenshot snapshots) against a running app, per key screen, with baselines and a tolerance threshold. Use for visual/design coverage of a test book or an app.
aptitude-gate
Decide release readiness of a QAIA test book or run - PASS / CONCERNS / FAIL / WAIVED - from the rubric score, hard coverage gates (AC, ADR 0001 negative-path), pending human arbitrations, and any execution results, recording the verdict and reasons in the standardized run manifest. Scores only - it judges readiness, it never edits test content. Use to gate a candidate before hand-off or CI.
automation-score
Score QAIA-generated Playwright test code on two separate tracks - a deterministic static pass plus a mutation pass that inverts each assertion and requires it to go red, then a 6-dimension LLM rubric for what no machine can see. Read-only over code - it judges, it never edits. Use to review generated automation before it is trusted, or to check whether a suite's assertions are load-bearing at all.
dataset-generate
Generate a rich, business-coherent synthetic test dataset (never real data or PII) from a QAIA user story or test book, covering realistic distributions and the boundary/edge cases the acceptance criteria demand, in a format directly injectable as a Playwright fixture. Use when a generated or automated test book needs concrete data instead of placeholder literals.
rag-build
Create or enrich the team's git-versioned QAIA knowledge base (.qaia/knowledge/) - glossary, business rules, application map, anomaly history - with a mandatory master index and small focused files. Use when capturing project knowledge or when another skill hands over a reusable rule.
signal-ingest
Ingest an exported production signal - an access-log extract, an error-rate table, a status-code breakdown, an APM export or a HAR capture - and attach it as evidence to the open questions a test book already carries. Answers nothing on its own - it turns a blind open question into an informed one. Use when a test book has open questions that observed behaviour could inform, or when production data exists and nobody has connected it to the test design.
test-plan-and-closure
Produce the two artefacts a test manager signs - a test plan derived from what the pipeline actually produced, and a closure report stating what was covered, what was not, and what remains open at delivery. Use before starting a campaign, at its end, or when someone above the tester asks what the testing effort covered.
confirm-fix
Close the loop on a defect - re-run the exact test that proved it, decide between closed, still open, and closed-but-something-else-broke, and never let the third verdict be reported as the first. Use after a fix is claimed, before closing a defect, or when asked whether a correction actually worked.
defect-report
Turn a failing test into a defect report a developer can act on - minimal reproduction, expected vs actual traced to its requirement, evidence-bounded severity, and the scenario ID that found it. Use when a run is red and someone has to fix it, when a finding must reach a tracker (GitHub, Jira, Azure DevOps), or when asked to write up an anomaly.
impact-select
From a diff and an existing Playwright suite, work out which tests to re-run, which may break, and what the change leaves uncovered - stating whether the answer is grounded in coverage data or is a declared hypothesis. Use on a pull request, before a targeted re-run, or when asked what a change puts at risk.
spec-suite-drift
Compare an OpenAPI specification against the test suite that claims to cover it - pure text, no running application. Reports status codes the suite uses that the spec never declares, error codes the spec promises that no test exercises, and endpoints the suite calls that the spec does not describe. Use when a project has both a formal API spec and an automated suite, and nobody has ever checked that they agree.
judge
Judge a test book, a Playwright suite, or a specification-versus-suite pair — whoever wrote them. Runs the pinned deterministic scorers first, then the semantic checklist, and returns a PASS/CONCERNS/FAIL gate with its reason named. Never edits what it judges. Use when someone asks whether tests are any good, whether a release candidate is ready, or whether a suite still matches the specification it claims to cover.
perf-check
Generate and run performance checks (latency budgets, concurrency integrity, named CT-PT test types - load/stress/spike/soak/scalability) against a self-hosted app, with k6 for real load. Use for performance coverage. Self-hosted targets only.
security-surface
Generate and run risk-based passive security-surface checks (CT-SEC - assets and threats identified first, then auth boundaries, IDOR, error handling, user enumeration prioritized by risk) against an authorized self-hosted app, plus optional OWASP ZAP baseline. Use for security coverage. Authorized self-hosted targets only.
istqb-design
Choose and justify ISTQB test design techniques (Foundation + CTAL-TA v4.0 + CT-AI) per acceptance criterion of an understood user story - equivalence partitioning, boundary values, decision tables, state transitions, scenario-based testing, combinatorial testing, domain testing, metamorphic testing, CRUD, AI/ML-feature testing. Use when deciding which test technique fits a requirement, when asked to justify test coverage methodologically, or when a test set looks like it was written by intuition and needs a defensible technique behind each case. Fourth step of the QAIA journey.
qaia
The QAIA Test Architect - a single conversational ReAct meta-agent that carries the whole journey. It reasons about the tester's intent, dispatches to the right journey skill, observes the result, and loops until the tester's goal is met. Use when the user wants to "work with QAIA" without naming a specific skill.
report
Project the QAIA journey into the standardized run manifest (.qaia/reports/<US-ID>/manifest.json) - the single machine-readable output contract every QAIA plugin shares, carrying normalized counts, coverage, confidence and provenance. Use after generating or exporting a test book, or when another plugin needs a uniform view of the run.
testbook-export
Export the generated test book for human rework and reporting - .feature files as source of truth, a natural-language rendering readable without Gherkin (verified step by step against its source), plus an XLSX and Markdown synthesis with coverage matrix, review order and confidence scores, plus opt-in file-only Xray and TestRail CSV exports (git-master mode, no API key). Use when test cases must leave the repository - handed to a test manager, imported into Xray, TestRail or Jira, reviewed in a spreadsheet, or attached to a release report. Seventh step of the QAIA journey.
testbook-generate
Generate the atomic Gherkin test book from prioritized test conditions - stable scenario IDs, coverage matrix, negative-ratio check, confidence marking - or regenerate by scenario-level diff when the US evolved, preserving human edits. Use when asked to write test cases or scenarios from a specification, to produce a test book or feature files, or to refresh an existing one after the requirement changed without losing hand-written edits. Sixth step of the QAIA journey.
testbook-validate
Audit an existing Gherkin test book (QAIA-generated or not) against the QAIA quality checklist - atomicity, coverage, negative ratio, traceability, ambiguity honesty - and produce a scored conformity report with a PASS/CONCERNS/FAIL gate decision. Use when the user wants a quality assessment of a test book.
automate
Generate native Playwright tests (Page Object Model as fixtures) from a QAIA Gherkin test book, preserving requirement traceability, plus a ready-to-run CI pipeline (GitHub Actions / GitLab CI / Jenkins) so the suite runs autonomously in the user's CI. E2E web and API. Web-first. Use when the user wants to automate an existing test book against a running app.
testbook-score
Score a QAIA test book against its source US with the ISTQB-grounded 10-dimension rubric (0/1/2 per dimension, /20) plus a top-3 fixes list, and record the score in the standardized run manifest. Read-only over test content - it judges, it never edits. Use to review a generated test book or gate a release candidate.
openapi-ingest
Ingest an OpenAPI or Swagger specification as the requirement source and derive test conditions from it - equivalence partitions from enums, boundaries from schema constraints, refusal paths from required fields and declared error codes, and the contradictions the specification carries. Use when an API has a formal spec instead of a user story, before istqb-design and testbook-generate.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.