jaktestowac/test-automation

Turns raw test run output (a CI log, JUnit or Playwright report, or console output) into failure clusters, likely root-cause groups, flakiness suspects, and what to investigate first. Use when a run has many failures and you need to triage them, or before a release decision on a red pipeline. For one failing test, use the explain-test-failure command.

Builds and tunes the CI jobs (GitHub Actions, GitLab CI, or similar) that run automated test suites: which suite runs on which trigger (PR smoke, full on merge, nightly matrix), sharding with merged reports, dependency and browser caching, trace and report artifacts with retention, a CI-only retry policy whose flakes are reported, running old and new suites side by side during a migration, separate performance and visual jobs, and a runtime budget that keeps feedback fast. Use when adding a test suite to CI, when the pipeline is too slow, when a failure in CI cannot be debugged because no trace or report was kept, when shards produce separate reports, or when suites need splitting by trigger. For merge-blocking gates, use generating-quality-gate-workflows.

Performs a quick review of a small diff, single file, function, or snippet: checks the change against its stated goal, names each finding with file:line, a severity, and a fix, and ends with a verdict. Use when the user asks to review, look over, or sanity-check a small, low-risk change before merging or pushing, including when the code is pasted inline and the request only asks whether anything is wrong. For multi-file pull requests, refactors, or high-risk areas, use code-review-advanced; for a test-code-only audit, use unslop-tests.

Performs a thorough, evidence-driven code review of pull requests, legacy modules, and quality-critical changes, returning severity-ranked findings with evidence and a merge recommendation. Use when the user asks for a deep or thorough review, or when the change spans many files, refactors architecture, or touches auth, payments, persistence, CI, shared test fixtures, or hot paths, and needs analysis of correctness, maintainability, security, performance, test quality, and operability risks. For a fast sanity check of a small, low-risk diff, use code-review; for a test-code-only audit of tests that prove nothing, use unslop-tests.

Decides the target shape of an automated test suite before it grows: which behaviour is tested at which layer, folder and project structure, fixtures versus page objects versus helpers versus screenplay, test data and auth strategy, configuration across environments, tag taxonomy, and ownership, with each significant choice recorded as a decision record. Use when starting a new suite, before a migration translates its first file, when an existing suite has grown inconsistent conventions, when E2E tests are doing the job of unit or API tests, or when a team argues about page objects, folder layout, or shared test accounts. For writing up a suite that already has a settled shape, use documenting-test-suites.

Diagnoses a failing test or a reported defect to its root cause: classifies the failure (application defect, test bug, environment or config, flaky, or test data), builds a tight reproduction loop that goes red on the exact symptom, tests ranked falsifiable hypotheses one variable at a time, and resolves it by class without weakening assertions. Use when a test fails on every run or since a merge, a CI job is red, someone asks "why is this failing", a bug is reported and needs a root cause, or a stack trace, error log, or trace file is pasted, even if the word debug is never used. When the failure is intermittent, hand over to stabilizing-flaky-tests; when the cause is an application defect, write it up with reporting-bugs.

Diagnoses one failing test from an error message, stack trace, CI log, or trace file and classifies the root cause as app defect, test bug, environment issue, or flakiness, without changing any code. Use when a test fails and you need to know why before deciding who fixes what. To have the failure fixed, use the fix-tests command; for a whole run with many failures, use the analyze-test-results command.

Runs the failing tests in a scope, diagnoses each failure, and fixes the root cause without weakening assertions, adding retries, or masking app defects. Use when tests fail consistently and you want them repaired. For intermittent failures, use the stabilize-flaky-tests command; to only diagnose without editing, use the explain-test-failure command.

Migrates UI tests from Cypress, Selenium, Puppeteer, or Protractor to Playwright Test while preserving what each test verifies: translates idioms instead of lines, runs both suites where possible, and reports a migration status per test. Use when moving a suite or part of one to Playwright. To restructure tests that are already in Playwright, use the refactor-to-page-objects command.

Migrates Cypress, Selenium, WebdriverIO, or Protractor suites to Playwright in staged slices, each with a parity gate before the old test is deleted. Use when porting a legacy browser suite, when deciding which tests are not worth porting, when a half-finished migration has stalled with two suites running in parallel, or when a suite migration needs a plan before anyone starts translating files.

Decides what to fake and fakes it correctly: mocking third-party APIs with Playwright route interception or HAR replay, MSW handlers, fake clocks that freeze time, and fixed timezones. Use when a UI, component, or unit test depends on a third-party service or API, when a date-sensitive test breaks overnight, when a suite is slow because it calls real services, or when a mocked test stays green while production is broken.

Explores a website with Playwright MCP, documents 3-5 core user flows with their locators and observed behaviour, and proposes test cases for each, saved under .qa/. Use when you need a first look at an unfamiliar app before planning or automating tests. To also capture the network requests behind each flow, use the playwright-explore-website-requests command; for a full risk-prioritized plan, use the create-test-plan command.

Explores a website with Playwright MCP and records, for 3-5 core user flows, the user actions, locators, and the network requests and responses each action triggers, saved to .qa/website-requests-exploration-summary.md. Use when you need to know which API calls sit behind the UI, for example before writing API tests, network mocks, or a HAR-based setup. When network traffic is not needed, use the playwright-explore-website command.

Generates a Playwright Test (TypeScript) spec from a scenario description by first walking through the scenario live with Playwright MCP, then running the generated test until it passes. Use when you have one scenario in words and a running app, and want a test grounded in the real UI rather than guessed locators. To generate tests for a whole written test plan file, use the test-generator command.

Refactors UI test specs into a Page Object Model without changing what they verify: extracts locators and actions into page or component objects, keeps assertions in the tests, and proves behaviour is unchanged by rerunning against a baseline. Use when specs repeat the same locators and action sequences, or before a suite grows past what copy-paste can maintain. For moving tests from another framework into Playwright, use the migrate-tests-to-playwright command.

Sets up and maintains visual regression testing with screenshot comparison: what to snapshot, baseline strategy, masking dynamic regions, threshold tuning, containerized baselines, and the review-and-update workflow. Use when styling regressions escape to production, when snapshots fail on every machine or every run, when baselines are being updated without being looked at, or when deciding whether visual testing is the right tool at all.

Reproduces intermittently failing tests with repeated and parallel runs, classifies the root cause (timing, isolation, data, environment), fixes it, and proves stability with before/after failure rates. Use when tests pass on retry, fail only in CI, or fail under parallel workers. For tests that fail every time, use the fix-tests command.

Diagnoses and fixes tests that fail intermittently, by root cause (timing, shared state, data collision, environment, order dependence, external dependency, or a real race in the application), proves the fix under the conditions that broke it, and contains what cannot be fixed yet with an owned, expiring quarantine. Use when a test fails randomly or passes on retry, when it passes locally but fails in CI, when a pipeline goes green after a re-run, when a suite needs retries to pass, when a flake list or quarantine keeps growing, or when someone proposes raising a timeout to make a failure go away. Applies even when the request never says flaky. For a test that fails on every run, use diagnosing-test-failures.

Creates, reviews, and modernizes static code analysis setups for Node.js and TypeScript repositories, covering ESLint flat config, typescript-eslint, tsconfig, Prettier, import sorting, Husky, lint-staged, package.json quality scripts, and CI quality gates. Use when setting up or auditing linting, formatting, type-checking, commit hooks, or GitHub Actions quality checks in a TypeScript project.

Audits automated test code for anti-patterns (fragile selectors, hardcoded waits, missing or swallowed assertions, test interdependence, CI misconfiguration, credential leaks) and produces a severity-ranked debt report with line citations, fixes, and an A-F health score. Use when reviewing a test suite or test PR, or when a suite has become slow, flaky, or hard to maintain. For repository-level debt such as skipped tests, disabled lint rules, and weakened CI gates, use the audit-quality-debt command.

Drives implementation test-first through red-green-refactor cycles, including multi-unit features built outside-in, legacy code without tests, and sessions that keep a written cycle log. Use when building a new behavior, when asked to fix a bug, or when changing what existing code does, and applies even when the code is pasted inline and the request does not mention tests. Also use whenever the request mentions TDD, test-first, red-green-refactor, or reproducing a bug with a failing test before fixing it, and when implementation keeps landing before anyone knows how it will be verified. For one small behavior or bug fix, test-driven-development-quick is enough; for tests added after the code exists, use writing-unit-tests.

Runs the red-green-refactor loop with a compact rule set for one small behavior or bug fix. Use for routine TDD on a single function or small change, or when the request asks to write the test first for something small. For larger features, legacy code, or a session that needs a cycle log, use test-driven-development.

Generates automated tests for the cases in a written test plan file, in the project's existing framework and conventions, runs them, and reports which pass, which fail, and which could not run. Use when a plan from create-test-plan, test-plan-basic, or manual-test-cases is ready to automate. To generate one test from a scenario description by walking it live first, use the playwright-generate-test command.

Cuts AI tells from test code: tests that pass without proving anything, tautological assertions, mock-only tests, hardcoded waits, coverage theater, vague names, swallowed errors, retries used as fixes. Use whenever test code is written, changed, or reviewed, including tests produced as a side effect of a feature task, and applies even when a test is pasted inline with only "good to ship?" and no request for review. Also use when the request mentions "are these tests any good", "this test always passes", or "clean up these tests". Must always apply to test code.

Writes and reviews focused, deterministic unit tests that verify behavior through public interfaces instead of implementation details. Use whenever tests are added to code that already exists, including backfilling tests on legacy code, and applies even when a function is pasted inline with a request to make sure it handles bad or unexpected input and tests are never mentioned. Also use when the request mentions unit tests, test coverage, edge cases, mocks or test doubles, or "this test breaks every refactor", and when reviewing an existing suite for brittleness, weak assertions, or missing boundary cases. For a few routine tests on one function, writing-unit-tests-quick is enough; when the tests should come before the code, use test-driven-development.

Writes a few solid unit tests with a compact set of rules for structure, assertions, determinism, and edge cases. Use for a few routine tests on one function, class, or small module, or a quick sanity check on tests someone just wrote. For legacy code, test-double design, or a full suite review, use writing-unit-tests.