qa-do

QA の多くの状況には、よく見られるパターンがあります。このスキルは、実行したいことや直面している問題の平易な説明をパターンに照合し、次に使うスキルを順番に1〜2個選びます。アクションの依頼であれば、それらのワークフローを実行します。どのスキルを選ぶべきかを尋ねられた場合は、推奨だけを返します。引数付きで呼び出された場合、状況は `$ARGUMENTS` です。それ以外の場合は、現在のタスクとプロジェクトの証拠から状況を推測します。

確認事項

まず .agents/qa-project-context.md を確認します。質問する前に、プロジェクトのマニフェスト、テスト、現在の変更、設定済みのターゲット、利用可能なツールを調べます。依頼された作業に影響するターゲットまたは要件が不足している場合に限り、質問します。

基本原則

1. 最も近いスキルではなく、最も的確なスキルに振り分けます。 広範なスキルとの曖昧な一致は、直接該当する狭いスキルよりも劣ります。「このバグを再現して」は、より広範な ai-bug-triage ではなく bug-reproduction に振り分けます。「Stripe のチェックアウトをテストして」は、汎用的な api-testing ではなく payment-testing に振り分けます。判断に迷った場合は、依頼の中にある具体的な成果物をトリガー語句に含むスキルを優先します。

2. スキルは順番に1つか2つだけにし、積み上げません。 出力するスキルは最大2つです。2つ目のスキルを選ぶのは、1つ目では明確な不足が残る場合に限ります（診断 → 測定、リスク → チェックリスト）。1つのスキルで依頼をカバーできる場合は「Direct」と伝えて実行します。3つのスキルに振り分ける必要があるなら、状況が曖昧ということなので、代わりに確認の質問をします。

3. 振り分け表が唯一の基準であり、古くなる可能性があります。 このルーターは特に内容がずれやすく、skills/ にスキルが追加されるたびに、ここに項目がない可能性があります。スキルが追加または削除されたら、skills/ に照らして振り分け表と「スキルカテゴリー」のリファレンスを再生成します。依頼に該当する項目がない場合は、誤った直接の振り分けを無理に行わず、「クイックリファレンス」の中で最も近いカテゴリーを使います。

使い方

実行したいことや直面している問題を説明してください。1〜2文で十分です。ルーターは、推奨するスキル（順番に1〜2個）と、それぞれの役割を説明するスキルごとに1行を出力します。例：「E2E テストが CI では失敗するのに、ローカルでは通ります。」→ test-reliability（不安定なテストや環境に左右されるテストを診断）、次に ci-cd-integration（パイプラインの環境をローカルの挙動に合わせる）。

アプリケーションのチェックを実行する

リポジトリ全体を利用できる場合は、リポジトリに用意された制約付きランナーを使います。作業ディレクトリが異なる場合も、<qa-skills> はこのチェックアウト、<project> はアプリケーションに解決します。

node <qa-skills>/scripts/qa.mjs plan --project <project> --goal "<user goal>"
node <qa-skills>/scripts/qa.mjs run --project <project> --goal "<user goal>"

計画に含まれる主要スキルと、次に関連するスキルを読み、それぞれのワークフローを実行します。ランナーは利用可能なテストコマンドを検出し、report.html、result.json、ログ、ホストへの引き継ぎ情報を書き出します。計画を立てただけではテストを実行したことになりません。個別のスキルしかインストールされていない場合は、それぞれの手順を直接実行し、同等の証拠を残します。

URL をチェックする場合は、具体的なターゲットと、アプリケーションが所有する準備完了セレクターを使用します。省略可能な連携機能が見つからなくても、無関係なローカル作業を止めずに、設定済みのチェックを実行します。ブラウザーがない、ターゲットを利用できない、テストを確認できない、またはテスト結果を読み取れない場合は、ブロックまたは未完了のままにします。スキップしたケースはそのまま残します。

失敗した場合は、再現してアサーションを保持し、ユーザーの依頼の範囲内である場合に限り修正を適用します。コードを変更した後は、再度実行します。失敗が続く場合は2回の試行で終了し、正確なブロッカーを報告します。アサーションを弱めたり、際限なく再試行したりしないでください。レポートが対象とするのは実行したチェックであり、普遍的な正しさではありません。設定とホスト連携については、リポジトリの docs/QA-RUNNER.md を参照してください。

よくある状況と対応するスキル

状況	推奨スキル	順序
新規プロジェクトで、テストがまったくない	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	直接
「エージェントにアプリを探索させて、結果を検証させる」	agentic-browser-testing	直接 — スクリプト不要の目標駆動型
「この PRD／仕様書／ストーリーからテストを書く」	ai-test-generation	直接
「この曖昧なバグを再現する／この報告を失敗するテストにする」	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	直接
「ユニットテストを書く／モックを追加する／カバレッジのしきい値を設定する」	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-reproduction → quality-postmortem	まず再現し、その後振り返り
「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	まず KPI を定義し、その後可視化
「サードパーティ 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 でバグを検出できず、遅すぎる」	shift-left-testing → test-planning	まずプロセスを変更し、その後計画
「AI／LLM 機能を構築していて、テストが必要」	ai-system-testing	直接
「このテストレポートを自然な文章にする／AI っぽさを減らす」	qa-report-humanizer	直接
「GDPR／EAA／AI Act に準拠していることを確認する」	compliance-testing	直接
「ステージング環境でカオス／障害注入を実施する」	chaos-engineering	直接

状況が曖昧な場合

説明が同じ比重で3つ以上のスキルに当てはまる場合は、確認の質問を1つすることで候補を絞り込めます。回答を受けてルーターはスキルを1～2個に絞ります。

• 「壊れたものを修正していますか、それとも新しいテスト範囲を一から作っていますか？」
• 「問題はプロセス（チームの働き方）ですか、それともツール（何が実行されているか）ですか？」
• 「優先事項はデリバリーの速さですか、それとも正しさへの確信ですか？」
• 「QA担当者はあなた一人ですか、それともチーム全体に関わる変更ですか？」

判別が必要な組み合わせ（推測せずに解決する4つの重複）

• test-reliability vs selector-drift-recovery — 実行時に修復される不安定なテストが1つの場合は 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、特定のバグを1つ再現して理解する場合は bug-reproduction です。
• qa-start vs qa-project-bootstrap — QAがまだいない新規プロジェクトの場合は qa-start、 既存のコードベースにQAエンジニアをオンボーディングする場合は qa-project-bootstrap です。

スキルカテゴリのクイックリファレンス

スキルに変更があった場合は、skills/*/SKILL.md の各 category: フィールドからこれを再生成してください。

カテゴリ	スキル
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

アンチパターン

• より的確なスキルがあるのに、広範なスキルに振り分ける。 「このバグを再現して」→ bug-reproduction（検証済みの再現を1件）ではなく、ai-bug-triage（一括分類）に振り分ける。修正方法：依頼に記載された具体的な成果物と、その成果物を名称に含むスキルを照合します。
• 1つの状況に3つ以上のスキルを積み重ねる。 これは徹底的ということではなく、曖昧さの表れです。 修正方法：確認の質問を1つして、1～2個に絞ります。
• 古い表を信用する。 最近追加されたスキルに行がないと、ルーターは気付かないまま、より弱い類似スキルに誤って振り分けます。修正方法：skills/ から表を再生成し（Core Principle 3）、 間違った候補を無理に選ぶのではなく、クイックリファレンスで最も近いカテゴリに振り分けます。
• 名前が付いた兄弟スキルに該当する依頼を引き受ける。 「新しいプロジェクトにQAをセットアップする」は qa-start、「プロジェクトのコンテキストを記録する」は qa-project-context です。qa-doは最後の手段としてのみ使います。

完了条件

• 次に使う1～2個のスキルが、現在のタスクに結び付いた理由とともに示されています。
• アクションの依頼では、チェックが実行されているか、具体的な阻害要因が記録されています。
• レポートに対象、ソースのリビジョン、コマンド、結果、残っている不足事項が記載されています。
• 作成済み、実行済み、失敗、スキップ、ブロック、未実行のチェックを区別できます。

関連スキル

• qa-start — このスキルと最も混同されやすい兄弟スキルです。QA がまだ整備されていない新規プロジェクトで QA を開始するときは、qa-do ではなくこちらを使用します。コンテキスト → 戦略 → 計画の順に進めます。
• qa-project-context — ほとんどのスキルを使用する前に、プロジェクトのセットアップ情報を記録します。すべてのスキルが最初にこれを確認します。再実装せず、こちらに案内してください。
• test-strategy — ルーティングすべき具体的な問題ではなく、「QA 戦略が必要」という状況で使用します。