@petrkindlmann/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

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

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

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

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.

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.