jaktestowac/qa-core

Turns rough tester notes, screenshots, logs, or observed behaviour into a developer-ready bug report with severity, reproducibility, confidence, and a missing-evidence checklist. Use when a defect has been observed and needs to be filed in Jira, GitHub Issues, or Linear. To diagnose why an automated test fails before filing, use the explain-test-failure command.

Shapes QA output for the person who has to act on it: result and blocker in the first two lines, one decision per report, findings ordered by what they cost, the long artifact in a file and the decisions in the message, and magnitude stated in units the reader can count. Use when a report is accurate but nobody acts on it, when a finding set is too long to read under time pressure, when the same findings must be retold for a developer, a release manager, and an on-call engineer, or when the request mentions "too long", "make this readable", "just tell me what to do", "so what", or "summarize this for stakeholders". Pairs with unslop-answers, which makes the same report honest.

Explores a web app (and its API, if given), maps features to risk, and produces a prioritized test plan with web and API scenarios, saved to .qa/test-plan.md. Use when starting test work on a new product or major feature, or when a plan must feed test-generator or manual-test-cases. For a quick single-pass plan from light exploration, use the test-plan-basic command.

Reads a function, module, or diff, derives white-box test cases from its actual branches, boundaries, and error paths, and marks each as covered, partial, or missing against existing tests. Use when code exists but its tests are thin, before refactoring legacy code, or when reviewing a diff for untested paths. To derive cases from requirements instead of code, use the manual-test-cases command.

Designs risk-based functional and regression test plans, manual test cases, and automation handoff packs from requirements, URLs, or exploratory notes. Use when a new feature or page needs a test plan or manual QA coverage before automation, turning feature descriptions into scenario catalogs, or converting exploratory findings into structured test assets.

Designs realistic, boundary-heavy, and role-aware test data packs for manual and automated testing. Use when a feature needs deliberate inputs and fixtures before execution, when edge-case values keep being improvised, or when automation needs stable example data with setup notes.

Writes the documentation a test suite needs to be usable by someone who did not build it: run instructions, environment setup, tag glossary, ownership, fixture and data notes, and architecture decision records. Use when onboarding someone into a suite, when "how do I run these" keeps being asked, when a test architecture decision needs recording, or when a suite is inherited with no documentation.

Generates risk-based Given/When/Then scenarios for one feature, weighted toward boundary values, invalid state transitions, and concurrency, and saves them to spec/edge-cases.md. Use when a feature with meaningful state (orders, payments, bookings, workflows) needs its edge cases enumerated before testing or automation. For a full .feature file from acceptance criteria, use the generate-gherkin-scenarios command; for security and adversarial lenses, use the qa-strategy command.

Explains the selected code, the active file, or a pasted snippet: purpose, control flow, patterns, risks, and what a tester should verify, adapted to a developer, tester, or non-technical audience. Use when you need to understand unfamiliar code before testing or reviewing it. To turn the code into a table of test cases with coverage status, use the derive-test-cases-from-code command.

Creates prioritized, timeboxed exploratory testing charters (Explore / with / to discover) from a feature description, release notes, or a short pass over a live app, each with test ideas, oracles, and setup needs. Use when planning exploratory sessions for a release, a risky change, or a feature too new for scripted cases. For scripted step-by-step cases, use the manual-test-cases command.

Converts a user story, acceptance criteria, or feature description into a declarative Gherkin .feature file (Given/When/Then) with scenario outlines for data variations, ready for Cucumber or Playwright-BDD. Use when a team writes BDD specs or wants acceptance criteria as living documentation. For a focused list of edge-case scenarios around states and boundaries, use the edge-case-scenario-generator command.

Designs a reusable test data catalog (valid baselines, boundaries, invalid inputs, role and state combinations) from requirements, constraints, a test plan, or the codebase, for manual and automated testing. Use when tests need concrete data sets, fixtures, or seed data, or when existing data misses boundaries and invalid cases.

Keeps test data legally and operationally safe: classifies personal data, replaces production copies with synthetic or anonymized fixtures, manages secrets in local runs and CI, strips personal data from traces and HAR files, and sets retention rules. Use when tests run against a production data copy, when fixtures contain real names or emails, when a data protection review is coming, or when test artifacts might carry personal data into CI logs.

Turns a feature description, acceptance criteria, exploratory notes, or a test plan into step-by-step manual test cases with priority, expected results, and automation candidates. Use when testers need executable cases for a feature, a release, or a UAT session. To derive cases from the code itself, use the derive-test-cases-from-code command; for exploratory session charters, use the generate-exploratory-charters command.

Builds a requirements traceability matrix from a PRD, user stories, or acceptance criteria against the existing tests: what is covered, at which level, what is missing, and which gaps carry the most risk. Saves it to .qa/requirements-coverage.md. Use when someone asks whether a feature is really tested, before a release sign-off, or when auditing coverage against a spec. To check a finished implementation against its criteria, use the verify-acceptance-criteria command.

Runs session-based exploratory testing: writes charters, timeboxes sessions, applies coverage heuristics and tours, captures notes as evidence, debriefs, and converts findings into bug reports and automation candidates. Use when a feature must be tested before its requirements are settled, when scripted cases keep passing while users hit problems, when a release has to be explored for risk in limited time, or when the request mentions charters or exploratory sessions.

Produces production-ready Product Requirements Documents (PRDs) for software systems and AI-powered features, with clear problem framing, measurable outcomes, scoped functionality, testable requirements, and explicit risks. Use when the user wants to write a PRD, define requirements, plan a feature, or turn a vague product idea into an implementation-ready specification.

Builds a scenario matrix for a feature, user story, or API spec across six lenses (happy path, boundary, negative, OWASP Top 10 security, adversarial sequences, data integrity), with an OWASP coverage table and open questions. Use when a feature handles input, auth, money, or shared data and you want its abuse cases listed before tests are written. For BDD edge cases around states and boundaries only, use the edge-case-scenario-generator command; for reviewing the requirements text itself, use the review-requirements command.

Turns a diff, PR summary, changed files, or hotfix description into a prioritized regression scope (must, should, sample, defer) with a minimal confidence suite and retest guidance for testers. Use when deciding what to retest before a release, after a hotfix, or when a full regression run does not fit the time available. For an automated gate on a diff with coverage and intent checks, use the scope-change-gate command.

Turns rough tester notes, screenshots, console output, or observed behavior into a reproducible bug report with severity, evidence, and follow-up guidance. Use when logging a bug or crash, triaging intermittent issues, or rewriting vague defect notes, and applies even when the user only describes what went wrong and asks to write it up for developers or a tracker such as Jira. To find the root cause of a failing test or defect, use diagnosing-test-failures.

Maps requirements (PRD, user stories, acceptance criteria) to planned test coverage via a Requirements Traceability Matrix, exposing coverage gaps, risks, test levels, prioritization, and automation candidates. Use when designing coverage from a specification, checking coverage completeness for a PRD or user story, finding missing acceptance criteria, or building a risk-based regression strategy. When the tests already exist and the matrix has to be extracted from them, verified, and kept accurate, use tracing-requirements-to-code; to check whether one build is done, use verifying-acceptance-criteria.

Reviews a user story, PRD, or acceptance criteria for ambiguity, contradictions, missing states, and untestable statements, and returns clarifying questions plus rewritten, testable acceptance criteria. Use when a story is about to enter implementation or sprint planning, or when it keeps getting reopened because people read it differently. To check whether a finished implementation meets its criteria, use the verify-acceptance-criteria command.

Produces a quick, single-pass test plan for a website from a short read-only exploration of its main flows, saved to .qa/basic-test-plan.md. Use when you need a starting plan for a small site, a smoke checklist, or a first pass before deeper planning. For a comprehensive, risk-prioritized plan with API scenarios and review rounds, use the create-test-plan command.

Builds and maintains bidirectional traceability between requirements and the tests that verify them: extracts a matrix from an existing codebase, annotates tests with requirement IDs, finds orphan tests and uncovered requirements, verifies that each link is real, and enforces linkage in CI. Use when a suite exists but nobody can say what it proves, when an auditor or stakeholder asks which tests cover a requirement, when a traceability matrix has gone stale, or when a requirement changes and its blast radius must be found. To plan coverage from a spec before tests exist, use requirements-test-coverage-mapper; to check whether one build is done, use verifying-acceptance-criteria.

Checks implementation evidence (code, PR, screenshots, API responses, or a running app) against acceptance criteria and marks each criterion Met, Partial, Not Met, or Untestable, with cited evidence and a sign-off summary. Use when a story is ready for review or sign-off, or when someone asks whether a feature does what was agreed. To review the criteria themselves before implementation, use the review-requirements command; to map requirements to existing tests, use the map-requirements-coverage command.

Checks whether one build or feature meets its acceptance criteria (ACs), showing from implementation evidence which criteria are met, partial, missing, or untestable without inventing missing behavior. Use when checking whether a story is done, preparing QA sign-off, or turning criteria and observations into a verification matrix. For planning coverage across a whole PRD, use requirements-test-coverage-mapper; for linking existing tests to requirement IDs, use tracing-requirements-to-code.