How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/petrkindlmann/qa-skills --skill qa-doBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
<objective> Most QA situations fit a recognizable pattern. This skill takes a plain-language description of what you're trying to do or what problem you're facing, matches it to a pattern, and names the 1-2 skills to use and in what order. It diagnoses and routes — it does not duplicate content from the skills it points to. If invoked with arguments, the situation is $ARGUMENTS; otherwise ask the user for a sentence or two describing it. </objective>
Core Principles
- Route to the most precise skill, not the nearest neighbor. A vague match to a
broad skill is worse than a direct hit on a narrow one. "Reproduce this bug" goes to bug-reproduction, not the broader ai-bug-triage; "test our Stripe checkout" goes to payment-testing, not generic api-testing. When in doubt, prefer the skill whose trigger phrases name the exact artifact in the request.
- One or two skills, in order — never a pile. Output at most two skills. A second
skill earns its place only when the first leaves a clear gap (diagnose → measure, risk → checklist). If one skill covers the request, say "Direct" and stop. Routing to three skills means the situation is ambiguous — ask a clarifying question instead.
- The routing table is the source of truth, and it goes stale. This router is uniquely
prone to drift: every skill added to skills/ is a row that may be missing here. Regenerate the table and the Skill Categories reference against skills/ whenever a skill is added or removed. If a request has no row, fall back to the closest category in the Quick Reference rather than forcing a wrong direct match.
How to Use
Describe what you're trying to do or what problem you're facing — a sentence or two is enough. The router outputs the recommended skill(s) (1-2, in order) and one line per skill explaining the role it plays. Example: "Our E2E tests keep failing in CI but pass locally." → test-reliability (diagnose flaky/environment-sensitive tests), then ci-cd-integration (align the pipeline environment with local behavior).
Common Situations and Their Skills
| Situation | Recommended Skills | Order |
|---|---|---|
| New project, no tests at all | qa-start (or qa-project-context → test-strategy) | Bootstrap the whole QA setup |
| Onboard a QA engineer to an existing codebase | qa-project-bootstrap | Direct — 30-day ramp + architecture audit |
| "Tests keep breaking in CI" | test-reliability → ci-cd-integration | Reliability first, then pipeline |
| "A UI refactor/redesign broke many selectors" | selector-drift-recovery | Direct — bulk regen, not per-test healing |
| "What should we test before this release?" | risk-based-testing → release-readiness | Risk first, then checklist |
| "We need Playwright tests" | playwright-automation | Direct |
| "We need Cypress tests" | cypress-automation | Direct |
| "Let an agent explore the app and assert outcomes" | agentic-browser-testing | Direct — goal-driven, no script |
| "Write tests from this PRD/spec/story" | ai-test-generation | Direct |
| "Reproduce this vague bug / turn this report into a failing test" | bug-reproduction | Direct — verified minimal repro + regression test |
| "Review my tests / find test smells" | ai-qa-review | Direct |
| "Our test suite is slow and flaky" | test-reliability → qa-metrics | Diagnose first, measure second |
| "Our suite is bloated / too many redundant tests" | test-suite-curation | Direct — audit + prune with evidence |
| "Manage / author manual test cases (TestRail, Xray, Zephyr, Qase)" | test-case-management | Direct |
| "Set up test reporting" | qa-dashboard → ci-cd-integration | Dashboard design, then CI wiring |
| "Test our API" | api-testing | Direct |
| "Write unit tests / add a mock / coverage threshold" | unit-testing | Direct |
| "Test our database / migration / data integrity" | database-testing | Direct |
| "Set up consumer-driven contract tests (Pact)" | contract-testing | Direct |
| "Where are our coverage gaps?" | coverage-analysis | Direct |
| "Do a structured exploratory / charter-based testing session" | exploratory-testing | Direct |
| "Check accessibility compliance" | accessibility-testing | Direct |
| "Test our payment / Stripe checkout / 3DS / subscription billing" | payment-testing | Direct |
| "Test the signup confirmation / password reset / OTP email flow" | email-testing | Direct |
| "Verify analytics / GA4 / pixel / dataLayer events fire correctly" | analytics-tracking-testing | Direct |
| "We got a bug in prod, understand why" | bug-reproduction → quality-postmortem | Reproduce first, then retro |
| "Classify / triage a batch of CI failures" | ai-bug-triage | Direct — batch failure clustering |
| "We're migrating from Selenium/Cypress" | test-migration | Direct |
| "Performance is degrading" | performance-testing → observability-driven-testing | Measure first, then trace |
| "Set up test data" | test-data-management | Direct |
| "Set up / containerize a test environment or staging" | test-environments | Direct |
| "Add tests to CI" | ci-cd-integration | Direct |
| "Visual changes breaking tests" | visual-testing → test-reliability | Baseline first, then stabilize |
| "We have no idea what quality looks like" | qa-metrics → qa-dashboard | Define KPIs, then surface them |
| "Third-party API is unreliable in tests" | service-virtualization | Direct |
| "Need to test on multiple browsers" | cross-browser-testing | Direct |
| "Need to test on real iOS/Android devices (Appium/Detox/Maestro)" | mobile-testing | Direct |
| "Security audit coming up" | security-testing | Direct |
| "Tests depend on each other and break in random order" | test-data-management → test-reliability | Fix data isolation first |
| "Roll out a feature safely (flags, canary) during release" | testing-in-production | Direct |
| "Schedule probes / SLA checks that run after release" | synthetic-monitoring | Direct |
| "Our QA is only catching bugs after dev, too late" | shift-left-testing → test-planning | Process change first, then plan |
| "We're building an AI/LLM feature and need to test it" | ai-system-testing | Direct |
| "Make this test report sound human / less AI-y" | qa-report-humanizer | Direct |
| "Make sure this is GDPR/EAA/AI Act compliant" | compliance-testing | Direct |
| "Run chaos / failure injection on staging" | chaos-engineering | Direct |
When the Situation is Ambiguous
If a description maps to three or more skills with equal weight, one clarifying question narrows it down. Answer it and the router reduces to 1-2 skills.
- "Are you fixing something broken, or building new coverage from scratch?"
- "Is this a process problem (how the team works) or a tooling problem (what's running)?"
- "Is the priority speed of delivery, or confidence in correctness?"
- "Are you the only QA, or is this a team-wide change?"
Disambiguation pairs (the four overlaps to resolve, not guess)
- `test-reliability` vs `selector-drift-recovery` — one flaky test healed at runtime →
test-reliability; many selectors broken by a planned UI refactor → selector-drift-recovery.
- `cross-browser-testing` vs `mobile-testing` — browsers/CSS engines →
cross-browser-testing;
real devices, Appium/Detox/Maestro, gestures/deep links → mobile-testing.
- `ai-bug-triage` vs `bug-reproduction` — classify/dedupe a batch of CI failures →
ai-bug-triage; reproduce and understand one specific bug → bug-reproduction.
- `qa-start` vs `qa-project-bootstrap` — brand-new project, no QA yet →
qa-start;
onboarding a QA engineer to an existing codebase → qa-project-bootstrap.
Skill Categories Quick Reference
Regenerate this from the category: field of every skills/*/SKILL.md whenever skills change.
| Category | Skills |
|---|---|
| Foundation | qa-project-context, qa-start, qa-do |
| Strategy | test-strategy, test-planning, risk-based-testing, exploratory-testing |
| Automation | playwright-automation, cypress-automation, api-testing, unit-testing, mobile-testing, visual-testing, performance-testing, cross-browser-testing, database-testing, security-testing, selector-drift-recovery |
| Specialized | accessibility-testing, payment-testing, email-testing, analytics-tracking-testing |
| AI-QA | ai-test-generation, ai-bug-triage, bug-reproduction, test-reliability, ai-qa-review, agentic-browser-testing |
| Infrastructure | ci-cd-integration, test-environments, test-data-management, contract-testing, service-virtualization |
| Metrics | qa-metrics, qa-dashboard, coverage-analysis |
| Process | shift-left-testing, qa-project-bootstrap, release-readiness, quality-postmortem, compliance-testing, qa-report-humanizer, test-case-management, test-suite-curation |
| Production | testing-in-production, synthetic-monitoring, observability-driven-testing |
| Knowledge | ai-system-testing, chaos-engineering, test-migration |
Anti-Patterns
- Routing to a broad skill when a precise one exists. "Reproduce this bug" → routing to
ai-bug-triage (batch classification) instead of bug-reproduction (single verified repro). Fix: match the exact artifact in the request to the skill that names it.
- Stacking three or more skills on one situation. That signals ambiguity, not thoroughness.
Fix: ask one clarifying question and reduce to 1-2.
- Trusting a stale table. If a recently added skill has no row, the router silently
mis-routes to a weaker neighbor. Fix: regenerate the table from skills/ (Core Principle 3) and fall back to the closest Quick Reference category rather than forcing a wrong match.
- Grabbing a request that belongs to a named sibling. "Set up QA on a new project" is
qa-start; "capture project context" is qa-project-context. qa-do is last resort only.
Related Skills
- qa-start — the sibling most confused with this one. Use it (not qa-do) when starting QA on a brand-new project with no QA in place; it chains context → strategy → planning.
- qa-project-context — capture project setup before using most skills; every skill checks for it first. Route here, don't reimplement it.
- test-strategy — when the situation is "we need a QA strategy" rather than a specific problem to route.
