qa-do

<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.