Back to Details

qa-do

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<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>
<objective> 大多数QA场景都符合可识别的模式。本Skill接收你想要完成的操作或遇到的问题的自然语言描述，将其与模式匹配，指出应使用的1-2个Skill及其顺序。它仅负责诊断和路由——不会复制所指向Skill的内容。如果调用时带有参数，则场景为`$ARGUMENTS`；否则请用户用一两句话描述场景。 </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.
  1. 路由到最精准的Skill，而非最接近的Skill。 模糊匹配宽泛Skill不如精准匹配细分Skill。「复现此bug」应路由到
    bug-reproduction
    ，而非更宽泛的
    ai-bug-triage
    ；「测试我们的Stripe结账流程」应路由到
    payment-testing
    ，而非通用的
    api-testing
    。如有疑问，优先选择触发短语与请求中明确提到的产物完全匹配的Skill。
  2. 最多推荐1-2个Skill，并指定顺序——绝不罗列多个。 输出最多两个Skill。只有当第一个Skill存在明显缺口时，才需要第二个Skill（例如：诊断→测量，风险→检查清单）。如果单个Skill即可覆盖请求，直接标注「直接调用」即可。若需要路由到三个Skill，说明场景存在歧义——此时应提出澄清问题。
  3. 路由表是唯一依据，但会过时。 本路由器特别容易出现偏差：
    skills/
    目录中新增的每个Skill都可能未被收录到路由表中。每当新增或移除Skill时，都需要根据
    skills/
    目录重新生成路由表和Skill分类参考。如果请求没有对应的路由条目，应退而求其次匹配快速参考中最接近的分类，而非强行错误匹配。

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).
用一两句话描述你想要完成的操作或遇到的问题即可。路由器会输出推荐的1-2个Skill（按顺序），以及每个Skill的作用说明（每行一个）。示例：「我们的E2E测试在CI中持续失败，但本地运行正常。」→ 
test-reliability
（诊断不稳定/环境敏感的测试），然后是
ci-cd-integration
（对齐流水线环境与本地环境的行为）。

Common Situations and Their Skills

常见场景及对应Skill

SituationRecommended SkillsOrder
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
场景推荐Skill顺序
全新项目，完全没有测试
qa-start
（或
qa-project-context
→ 
test-strategy
）		搭建完整的QA体系
为现有代码库的QA工程师提供入职培训
qa-project-bootstrap
直接调用——30天快速上手 + 架构审计
「测试在CI中持续失败」
test-reliability
→ 
ci-cd-integration
先解决可靠性问题，再处理流水线问题
「UI重构/重新设计导致大量选择器失效」
selector-drift-recovery
直接调用——批量重新生成选择器，而非逐个修复测试
「发布前我们应该测试什么？」
risk-based-testing
→ 
release-readiness
先进行风险评估，再使用检查清单
「我们需要Playwright测试」
playwright-automation
直接调用
「我们需要Cypress测试」
cypress-automation
直接调用
「让Agent探索应用并验证结果」
agentic-browser-testing
直接调用——目标驱动，无需脚本
「根据PRD/需求文档/用户故事编写测试」
ai-test-generation
直接调用
「复现这个模糊的bug / 将bug报告转化为失败测试用例」
bug-reproduction
直接调用——生成可验证的最小复现用例 + 回归测试
「审核我的测试 / 找出测试异味」
ai-qa-review
直接调用
「我们的测试套件运行缓慢且不稳定」
test-reliability
→ 
qa-metrics
先诊断问题，再进行度量
「我们的测试套件冗余过多 / 存在大量重复测试」
test-suite-curation
直接调用——基于证据进行审计和精简
「管理/编写手动测试用例（TestRail、Xray、Zephyr、Qase）」
test-case-management
直接调用
「设置测试报告」
qa-dashboard
→ 
ci-cd-integration
先设计仪表盘，再接入CI流水线
「测试我们的API」
api-testing
直接调用
「编写单元测试 / 添加Mock / 设置覆盖率阈值」
unit-testing
直接调用
「测试我们的数据库 / 数据迁移 / 数据完整性」
database-testing
直接调用
「设置消费者驱动的契约测试（Pact）」
contract-testing
直接调用
「我们的测试覆盖率缺口在哪里？」
coverage-analysis
直接调用
「进行结构化探索性/基于章程的测试会话」
exploratory-testing
直接调用
「检查无障碍合规性」
accessibility-testing
直接调用
「测试我们的支付/Stripe结账/3DS/订阅计费流程」
payment-testing
直接调用
「测试注册确认/密码重置/OTP邮件流程」
email-testing
直接调用
「验证分析工具/GA4/像素代码/dataLayer事件是否正确触发」
analytics-tracking-testing
直接调用
「生产环境出现bug，需要了解原因」
bug-reproduction
→ 
quality-postmortem
先复现bug，再进行复盘
「分类/批量处理CI失败用例」
ai-bug-triage
直接调用——批量失败聚类
「我们正在从Selenium/Cypress迁移」
test-migration
直接调用
「性能持续下降」
performance-testing
→ 
observability-driven-testing
先度量性能，再追踪问题
「设置测试数据」
test-data-management
直接调用
「设置/容器化测试环境或预发布环境」
test-environments
直接调用
「在CI中添加测试」
ci-cd-integration
直接调用
「视觉变更导致测试失败」
visual-testing
→ 
test-reliability
先建立基准，再稳定测试
「我们完全不清楚当前的质量状况」
qa-metrics
→ 
qa-dashboard
先定义关键绩效指标，再可视化展示
「第三方API在测试中不可靠」
service-virtualization
直接调用
「需要在多个浏览器上测试」
cross-browser-testing
直接调用
「需要在真实iOS/Android设备上测试（Appium/Detox/Maestro）」
mobile-testing
直接调用
「即将进行安全审计」
security-testing
直接调用
「测试之间相互依赖，随机顺序运行会失败」
test-data-management
→ 
test-reliability
先修复数据隔离问题
「发布期间安全推出功能（特性开关、金丝雀发布）」
testing-in-production
直接调用
「安排发布后的探测/SLA检查」
synthetic-monitoring
直接调用
「我们的QA仅在开发完成后发现bug，为时已晚」
shift-left-testing
→ 
test-planning
先调整流程，再进行测试规划
「我们正在开发AI/LLM功能，需要进行测试」
ai-system-testing
直接调用
「让这份测试报告更像人工撰写/减少AI痕迹」
qa-report-humanizer
直接调用
「确保符合GDPR/EAA/AI法案合规要求」
compliance-testing
直接调用
「在预发布环境中进行混沌工程/故障注入测试」
chaos-engineering
直接调用

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?"
如果某个描述同时匹配三个或更多Skill且权重相当，提出一个澄清问题即可缩小范围。用户回答后，路由器就能将推荐Skill减少到1-2个。
  • 「你是在修复已有的问题，还是从零开始搭建新的测试覆盖？」
  • 「这是流程问题（团队协作方式）还是工具问题（运行环境）？」
  • 「优先级是交付速度，还是正确性保障？」
  • 「你是唯一的QA，还是这是团队层面的变更？」

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
    .
  • test-reliability
    vs 
    selector-drift-recovery
     ——单个不稳定测试在运行时修复 → 
    test-reliability
    ；因计划内UI重构导致大量选择器失效 → 
    selector-drift-recovery
    。
  • cross-browser-testing
    vs 
    mobile-testing
     ——浏览器/CSS引擎测试 → 
    cross-browser-testing
    ；真实设备、Appium/Detox/Maestro、手势/深度链接测试 → 
    mobile-testing
    。
  • ai-bug-triage
    vs 
    bug-reproduction
     ——分类/去重批量CI失败用例 → 
    ai-bug-triage
    ；复现并理解单个特定bug → 
    bug-reproduction
    。
  • qa-start
    vs 
    qa-project-bootstrap
     ——全新项目，尚未建立QA体系 → 
    qa-start
    ；为现有代码库的QA工程师提供入职培训 → 
    qa-project-bootstrap
    。

Skill Categories Quick Reference

Skill分类快速参考

Regenerate this from the 
category:
field of every 
skills/*/SKILL.md
whenever skills change.
CategorySkills
Foundationqa-project-context, qa-start, qa-do
Strategytest-strategy, test-planning, risk-based-testing, exploratory-testing
Automationplaywright-automation, cypress-automation, api-testing, unit-testing, mobile-testing, visual-testing, performance-testing, cross-browser-testing, database-testing, security-testing, selector-drift-recovery
Specializedaccessibility-testing, payment-testing, email-testing, analytics-tracking-testing
AI-QAai-test-generation, ai-bug-triage, bug-reproduction, test-reliability, ai-qa-review, agentic-browser-testing
Infrastructureci-cd-integration, test-environments, test-data-management, contract-testing, service-virtualization
Metricsqa-metrics, qa-dashboard, coverage-analysis
Processshift-left-testing, qa-project-bootstrap, release-readiness, quality-postmortem, compliance-testing, qa-report-humanizer, test-case-management, test-suite-curation
Productiontesting-in-production, synthetic-monitoring, observability-driven-testing
Knowledgeai-system-testing, chaos-engineering, test-migration
每当Skill发生变化时，需根据所有
skills/*/SKILL.md
文件中的
category:
字段重新生成此表格。
分类Skill
基础类qa-project-context, qa-start, qa-do
策略类test-strategy, test-planning, risk-based-testing, exploratory-testing
自动化类playwright-automation, cypress-automation, api-testing, unit-testing, mobile-testing, visual-testing, performance-testing, cross-browser-testing, database-testing, security-testing, selector-drift-recovery
专项测试类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
基础设施类ci-cd-integration, test-environments, test-data-management, contract-testing, service-virtualization
度量类qa-metrics, qa-dashboard, coverage-analysis
流程类shift-left-testing, qa-project-bootstrap, release-readiness, quality-postmortem, compliance-testing, qa-report-humanizer, test-case-management, test-suite-curation
生产环境测试类testing-in-production, synthetic-monitoring, observability-driven-testing
知识类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.
  • 存在精准Skill时却路由到宽泛Skill。 例如「复现此bug」→ 路由到
    ai-bug-triage
    （批量分类）而非
    bug-reproduction
    （单个可验证复现）。修复方式：将请求中明确提到的产物与对应Skill匹配。
  • 单个场景路由到三个或更多Skill。 这表明场景存在歧义，而非考虑周全。修复方式：提出一个澄清问题，将推荐Skill减少到1-2个。
  • 依赖过时的路由表。 如果最近新增的Skill未被收录到路由表中，路由器会自动错误路由到相近的Skill。修复方式：根据
    skills/
    目录重新生成路由表（核心原则3），并退而求其次匹配快速参考中最接近的分类，而非强行错误匹配。
  • 接管本应属于其他明确Skill的请求。 例如「为新项目搭建QA体系」属于
    qa-start
    ；「收集项目上下文信息」属于
    qa-project-context
    。qa-do仅作为终极方案使用。

Related Skills

关联Skill

  • 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.
  • qa-start ——最容易与本Skill混淆的同类Skill。当为完全没有QA的新项目启动QA工作时，请使用它（而非qa-do）；它会串联上下文→策略→规划的流程。
  • qa-project-context ——在使用大多数Skill之前需收集项目配置信息；所有Skill都会首先检查此信息。应路由到该Skill，而非自行实现相关功能。
  • test-strategy ——当场景为「我们需要一个QA策略」而非具体问题时，应使用该Skill。