Shivani26Singh
User28 reusable Agent Skills (SKILL.md) for the full QA lifecycle plus Playwright test automation — for Claude Code, GitHub Copilot, and similar AI coding assistants. Every skill drafts a review-ready output; a human confirms before anything ships.
Categories
Indexed Skills (28)
pw-api-tester
Designs and generates Playwright API tests — JavaScript or TypeScript — using the `request` fixture / `APIRequestContext` to validate an endpoint's contract: status, schema, auth/authorization, and negative and boundary behavior. Use when an SDET says "write API tests for this endpoint", "test the /orders API", "add schema validation for this response", "cover the negative cases", or pastes an OpenAPI/endpoint spec. Produces a draft the engineer runs against a real service — never a proven-green suite.
pw-ci-configurator
Designs CI-platform-neutral Playwright execution — JavaScript or TypeScript — covering parallelism, sharding, retries, reporters, and failure artifacts, without assuming a specific CI provider. Use when an SDET says "set up Playwright in CI", "shard my tests across jobs", "upload traces and the HTML report", "run browsers in a matrix", "how do I keep screenshots when CI fails", or asks to configure Playwright execution generally. Produces `playwright.config` changes and an execution strategy — provider-specific YAML/scripts only when the platform is actually known.
pw-fixture-designer
Designs reusable Playwright test fixtures — JavaScript or TypeScript, matched to the target project's conventions — providing common test dependencies such as authentication/session state, seeded test data, page objects, API-created resources, and environment setup. Use when an SDET says "create an auth fixture", "I need a logged-in page fixture", "set up test data fixtures", "share a page object via fixture", or wants to stop repeating login/setup in every test. Produces a fixtures module with correct scope and teardown — a draft the engineer wires in and runs.
pw-flaky-debugger
Diagnoses a flaky Playwright test — JavaScript or TypeScript — by collecting evidence (trace, rerun history, network/console logs), classifying the root cause against an evidence-ranked rubric (product, test, environment, or data), and proposing the smallest deterministic fix. Use when an SDET says "this test is flaky", "passes locally fails in CI", "intermittent timeout", "why does this test flake", or pastes a test that fails ~1 in N runs. Never classifies from a stack trace or error message alone, and never quarantines or "fixes" a real product bug just to make CI green — a diagnosis the engineer reproduces and confirms.
pw-locator-fixer
Audits a Playwright spec or Page Object for brittle locators — XPath, CSS classes, nth-child/positional selectors, deep DOM chains — and proposes resilient, JavaScript- or TypeScript-matched replacements without changing test intent. Use when an SDET says "fix these locators", "my selectors are flaky", "replace XPath with getByRole", "review the selectors in this Page Object", or reports a strict-mode violation. Produces a before/after rewrite map plus reasoning — the engineer verifies each swap against the real DOM.
pw-mobile-tester
Sets up Playwright mobile/responsive web testing — device emulation across real device descriptors, touch/gesture interactions, breakpoint and orientation coverage, network throttling, geolocation, and mobile-specific accessibility (touch target size). Use when an SDET says "test this on mobile", "check the responsive breakpoints", "simulate a swipe/tap", "test under slow 3G", or "test geolocation on a phone". Applies only when the application actually has a responsive/mobile web UI to test — produces device-project config and test drafts the engineer runs against the real app.
pw-multi-tab-handler
Writes race-free Playwright code for any flow that opens a second tab, popup, or window — target="_blank" links, "open in new window" buttons, OAuth/SSO consent screens, payment redirects, and PDF preview tabs. Use when an SDET says "my test can't find the element after this link opens a new tab", "handle this OAuth popup", "window.open breaks my test", or a test needs to manage several open tabs at once. Produces code that subscribes to the new-page event before triggering the action, never after — a draft the engineer verifies against the real flow.
pw-network-mocker
Designs Playwright route interception and mocking — JavaScript or TypeScript — to make UI tests deterministic without diverging from the real API contract. Use when an SDET says "mock this API", "stub the /orders response", "force a 500 error state", "make this test deterministic without the backend", or "intercept network calls". Produces `page.route`/`fulfill` handlers to stub responses, simulate errors/slow/aborted states, and remove backend flakiness — a draft the engineer wires in and verifies against the real contract.
pw-page-object-builder
Designs and generates maintainable Playwright Page Object Model (POM) classes — JavaScript or TypeScript, matched to the target project's conventions — from a described page, existing test, UI flow, or provided page structure. Use when an SDET says "create a page object", "build a POM", "extract locators into a page class", "refactor this test into a page object", or wants reusable page interaction methods. Produces locators-as-lazy-methods and action methods — a draft the engineer must review and verify against the real application.
pw-suite-auditor
Audits an existing Playwright suite — JavaScript or TypeScript — against the pack's best practices and produces a prioritized migration plan that names which specialized skill (pw-locator-fixer, pw-page-object-builder, pw-fixture-designer, pw-flaky-debugger, pw-api-tester, pw-network-mocker, pw-visual-regression, pw-ci-configurator, pw-test-health-reporter) to run on which file. Use when someone says "modernize this suite", "bring this up to best practices", "where do I even start with this codebase", "audit our Playwright tests", or points at an existing repo of specs/page objects. Makes no code changes itself — it is a router, not a fixer.
pw-test-generator
Generates a Playwright test spec — JavaScript or TypeScript, matched to the target project's existing conventions — from a described user flow or scenario. Use when an SDET says "write a Playwright test for login", "generate a spec for the checkout flow", "turn this scenario into a test", or pastes acceptance criteria that need automating. Detects the project's language and conventions, reuses existing fixtures/page objects, and produces a runnable draft using semantic locators and web-first assertions — the engineer still runs it.
pw-test-health-reporter
Analyzes Playwright suite health across multiple runs — JavaScript or TypeScript project — preferring the playwright-flaky-analyzer CLI/reporter when the project has it (deterministic passing/flaky/fixed/newly-failing/ consistently-failing/skipped classification, 21 root-cause rules, Common Errors grouping, HTML/JSON/Markdown output, an opt-in --max-flaky CI gate), and falling back to manual multi-run analysis when it doesn't. Use when someone asks "how healthy is our test suite", "which tests are flakiest", "show me tests linked to open bugs", "find stale skipped tests", or wants to run/interpret a playwright-flaky-analyzer report. Also cross-references tests skipped/fixme'd against a real bug ID in source — something the tool itself doesn't check — flagging stale or untracked ones. Does not diagnose any single failure in depth.
pw-test-step-reporter
Structures a Playwright test so it explains itself in the HTML report — test.step for logical phases, testInfo.attach for evidence (screenshots, JSON, diffs), expect.soft with a hard gate for grouped checks, and annotations for issue/bug-ID traceability. Use when an SDET says "make this test's report readable", "group this into steps", "attach a screenshot to the report", "how do I do soft assertions", or "why can't I tell which step failed in CI". Produces a report a human can debug from without re-running the test — a draft the engineer reviews and runs.
pw-trace-analyzer
Analyzes a Playwright trace.zip or failure artifact — JavaScript or TypeScript project — to reconstruct the failure timeline, correlate DOM/ network/console evidence, and classify whether the root cause is in the test, a locator, the application, test data/config, or the environment. Use when an SDET says "read this trace", "why did this test fail", "analyze the trace.zip", "my CI run failed — what broke", or pastes an error plus trace. Produces an evidence-driven diagnosis — the engineer confirms it by re-running.
pw-visual-regression
Sets up and reviews Playwright visual/screenshot regression testing — JavaScript or TypeScript — to catch meaningful visual regressions while minimizing false positives from nondeterministic rendering or dynamic content. Use when an SDET says "add visual regression", "snapshot this component", "set up toHaveScreenshot", "mask the dynamic parts of this page", "why does my screenshot test keep failing", or "manage baselines". Produces snapshot tests with masking, thresholds, and a baseline strategy — a draft the engineer runs to generate and review the first baselines.
requirement-readiness-analyzer
Assess whether a requirement (user story, feature, or acceptance criteria) is sufficiently complete, unambiguous, and testable to be ready for QA activities. Use when a tester says "analyze this ticket", "is this story ready to test", "find gaps in this requirement", or pastes a story / acceptance criteria and wants it pressure-tested. Retrieves the requirement from any configured project-management integration (or accepts pasted text), evaluates it against a readiness checklist, and returns an advisory readiness score and confidence level plus a gaps / ambiguities / risks report and clarifying questions for the requirement owner.
test-plan-generator
Turn a requirement into a review-ready test plan. Use when a tester or QA lead says "write a test plan for this story", "plan testing for this feature", "what should we test here", or pastes a user story / acceptance criteria. Retrieves the requirement (or accepts pasted text), organizes scope, strategy, risks, gaps, entry/exit criteria, and a high-level scenario summary, then stops for human review. Produces the plan (WHAT and HOW-broadly to test), not detailed test scenarios, test cases, an RTM, automation, or test data.
api-test-designer
Design API-level test coverage from an endpoint or contract. Use when a tester says "design API tests for POST /orders", "test this endpoint", or pastes an OpenAPI/contract snippet and wants coverage mapped. Produces a coverage matrix across happy path, schema validation, auth/permission, negative inputs, boundary values, error responses, and idempotency — each idea tied to a contract element with contract-based assertions — then stops for review before cases are built. Identifies WHAT to validate, not executable tests, payloads, or scripts.
test-scenario-designer
Derive high-level test scenarios from a requirement or acceptance criteria before anyone writes detailed steps. Use when a tester says "what scenarios should we test", "design scenarios for this feature", or pastes ACs and wants coverage mapped out. Produces positive, negative, boundary, cross-role, cross-state, and non-functional scenarios — each categorized, risk-tagged, and traced to the AC it exercises — then stops for review before test cases are written. Identifies WHAT to test, not HOW; detailed steps and data belong to the Test Case & RTM Generator.
test-case-writer
Generate enterprise-grade QA artifacts from requirements: manual test cases, BDD scenarios, automation assessment, a Requirement Traceability Matrix (RTM), and coverage gap analysis. Use when a tester provides a user story, acceptance criteria, PRD/BRD, specification, wireframe, screenshot, or supporting document and wants traceable Story → Acceptance Criteria → Test Case coverage. Produces only evidence-supported artifacts and flags missing information as clarification gaps rather than inventing behavior.
test-data-generator
Generate realistic, safe, and traceable test data from field, entity, or schema definitions. Use when a tester says "generate test data", "give me boundary values for this field", or needs valid, invalid, boundary, relational, or bulk synthetic records to drive test cases. Returns labeled data sets — each tied to the field, constraint, or scenario it exercises, with the expected outcome and the environments it is safe to use in. Produces only evidence-supported data and never real production or customer data.
regression-suite-selector
Select a risk-ranked regression subset for a change instead of running the full suite. Use when an engineer or tester says "what regression should I run for this PR", "pick regression tests for this change", or describes a change area and wants the affected tests identified — a diff, a changed- file list, and a plain-language description of the change are all supported inputs; PR or repository access is never required. Maps the change to the tests that exercise it, ranks Must-run / Should-run / Skip- with-reason, and always keeps a smoke/critical safety net. The selection is advisory — a human confirms before any test is dropped from the run.
test-execution-tracker
Log and roll up the execution of a test cycle. Use when a tester says "log this run", "track execution for the sprint", or reports results case by case and wants them recorded. Captures pass / fail / blocked / not-run per case with evidence, run owner, and environment, then computes completion %, pass rate, and blocker counts with denominators shown. Records only what was actually reported; an unverified or unreported case stays "not run", never assumed green. Does not file defects or make a go/no-go call — those belong to the Bug Reporter and Test Closure Reporter.
bug-reporter
Turn a failure into a clear, reproducible, evidence-based defect report. Use when a tester says "file a bug for this", "write up this defect", or describes something broken and wants it documented properly. Produces a structured report — title, environment, reproduction steps, expected vs actual, severity/priority, evidence, reproducibility, and suspected area — ready to paste into the tracker after a human confirms it. When a Jira MCP integration is available, also optionally checks Jira for an existing or duplicate defect and recommends whether to file a new issue or attach to an existing one; this check never creates, updates, or closes a Jira issue itself, and is skipped without failing if Jira MCP is unavailable. Reports only observed facts; never invents a reproduction step, log line, or conclusion.
bug-triage-assistant
Triage a batch of defects instead of grinding through them one by one. Use when a lead says "triage these bugs", "prioritize the defect backlog", or pastes a list of open issues that need sorting. Groups likely duplicates, proposes severity/priority, routes each to a component or owner, flags reports missing information, and summarizes backlog health. Every duplicate and routing is a suggestion for a human to confirm — it never auto-closes, merges, or reassigns silently.
rca-analyzer
Run a structured root-cause analysis on a defect, escape, or incident. Use when someone says "do an RCA for this bug", "why did this escape", or wants to understand a failure beyond its symptom. Reconstructs the timeline, applies 5-Whys and a fishbone across people, process, tooling, data, and environment, separates root cause from symptom, analyzes the escape point, and proposes corrective and preventive actions (CAPA). Reasons only from supplied evidence; unproven links are marked as hypotheses to verify.
test-closure-reporter
Produce the closure report that wraps up a test cycle. Use when a lead says "write the test closure report", "summarize the test cycle", or needs an end-of-cycle summary for sign-off. Pulls the metrics — pass rate, execution completion, defect density, open criticals, requirement coverage — into highlights, risks, exit-criteria status, and an advisory go/no-go recommendation. The recommendation is advisory only: it lays out the evidence, but a human owns the sign-off. Uses real, auditable numbers, never invented ones.
test-coverage-analyzer
Find the gaps between what was required and what was actually tested. Use when a lead says "where are our coverage gaps", "what isn't tested", or wants requirements checked against the designed, automated, and executed tests. Builds a traceability view across Requirement → Acceptance Criteria → Test Case → Automation → Execution, then surfaces untested requirements, thin coverage, executed-but-failing coverage, and orphan tests — ranked by risk. Reports only from supplied artifacts; never assumes coverage without traceable evidence.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.