1.2万 件 ・ 関連度順
概要と使いどころ
ISTQB/JSTQB のテスト実装（test implementation）活動を支援するスキル。test-design が導出したテストケースを、実行できる形に具体化する。自動テストなら実行手順（テストコード・テストデータ・テストダブル）をコンパイル/構文レベルの動作確認まで、手動テストなら手順書・テストデータ・環境準備手順を作る。「テストケースを実装して」「テストコードに落として」「テスト手順書を作って」「テストデータ・モックを用意して」と依頼されたときに使う。テスト対象の検証としての実行（結果の解釈・欠陥候補整理）は test-execute の担当でここではしない。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-implement <テスト対象名> で明示的に呼び出されたときのみ使用する。
テストの追加・補強・作り直し。TDDモード（実装前テスト先行生成）にも対応。 Playwright・Jest等のE2Eテスト、ユニットテスト、APIテストの新規作成・補強を行う。 「テストを書いて」「カバレッジを上げて」「テストを作り直して」「E2Eテストを作って」 「自動テストを作成して」「Playwrightでテストして」「操作テストを作って」 「○○のテストを実装して」「バックエンドテストを作って」などのリクエストで使用する。
新規・既存テストが守る動作と不具合を確かめ、重複や実装への依存を見直すスキル。削除の根拠を整理し、必要な検証を残してテスト用コードも整理します。
ISTQB/JSTQB のテスト設計（test design）活動を支援するスキル。test-analyze が識別したテスト条件から、テスト対象の特性に応じたテスト技法（同値分割・境界値分析・デシジョンテーブル・状態遷移・カバレッジ基準・エラー推測など）を選定提案し、承認された技法で具体的なテストケース（入力値・前提・期待結果）を導出して、設計書 test-design.md（技法選定根拠・カバレッジ）とケース一覧 test-case.md の 2 本を作る。「テストケースを作って」「テストケースを設計して」「どの技法で網羅すべきか提案して」「境界値/デシジョンテーブルでテストを起こして」と依頼されたときに使う。テストコード実装（test-implement）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-design <テスト対象名> で明示的に呼び出されたときのみ使用する。
ISTQB/JSTQB のテスト分析（test analysis）活動を支援するスキル。テストベース（仕様・設計・コード・リスク）を分析して「何をテストすべきか」= テスト条件（test condition）を識別し、test-plan のプロダクトリスク評価があればそれを入力に優先度を付けた test-analysis.md を作る。「何をテストすべきか洗い出して」「テスト条件を整理して」「テスト観点を出して」「テスト分析して」と依頼されたときに使う。テストケースの導出（test-design）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-analyze <テスト対象名> で明示的に呼び出されたときのみ使用する。
アプリのテストはすべてこのスキルを使う。開発中のTDD（テストファースト）から、 ユーザー目線のE2E・受入テスト、インフラ/デプロイ検証、リリース前の網羅テストまでを1つに統合。 「テストを書いて」「テストして」「動作確認して」「TDDで進めて」「カバレッジを確認」 「E2Eテスト」「リリース前にちゃんとテストしたい」「本番で動くか確認」「回帰テスト」 などの文脈で必ず使用する。§0「適用段階」に従い、たたき台〜v1 では「壊れたら困る順」の最小テスト、 固定化段階(v1 到達後のブラッシュアップ)ではユーザーがテストと明示しなくてもTDDサイクルを適用する。 セキュリティ・コスト・パフォーマンスの監査は Skill launch-security を併用する。
ISTQB/JSTQB のテスト実行（test execution）活動を支援するスキル。test-implement が具体化したテストを実行し、結果を記録し、失敗を欠陥候補として整理して test-execution-log.md にまとめる。自動テストならランナーを実行し結果を解釈、手動テストなら利用者の実施結果を聞き取って記録する。失敗は欠陥候補として整理し、外部 issue 化は提案に留める。「テストを実行して結果を記録して」「テスト実行ログを作って」「失敗を欠陥として整理して」「手動テストの結果を記録して」と依頼されたときに使う。ワークフローの test-targeted（修正範囲にテストランナーを絞り込んで実行するだけ）とは別物で、こちらは ISTQB プロセスとしての実行・記録・欠陥候補整理を成果物 test-execution-log.md に残す。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-execute <テスト対象名> で明示的に呼び出されたときのみ使用する。
ISTQB/JSTQB のテスト計画（test planning）活動を支援するスキル。テスト対象のプロダクトリスク（product risk）を発生可能性×影響度で識別・評価し、それを根拠にテストアプローチ（どこを厚くテストするか）・開始基準（entry criteria）・完了基準（exit criteria）を定めた test-plan.md を作る。「テスト計画を立てて」「テスト戦略を決めたい」「何をどこまでテストすべきか整理して」「リスクベースでテスト範囲を決めたい」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-plan <テスト対象名> で明示的に呼び出されたときのみ使用する。
ISTQB/JSTQB のテスト完了（test completion）活動のうち、テスト実行結果の評価と完了基準（exit criteria）判定を支援するスキル。テスト実行ログ（test-execution-log.md）と test-plan の完了基準を突き合わせ、完了とみなせるかを判定した test-summary-report.md を作る。テスト完了時の最終レポートにも、テスト途中の中間評価にも使える。「テスト結果をまとめて」「完了基準を満たしたか判定して」「テストレポートを書いて」「今どこまでテストが進んだか評価して」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-report <テスト対象名> で明示的に呼び出されたときのみ使用する。
This skill should be used when the user asks to "dev-webtest-plan", "Webテスト計画を生成", "テスト計画を作成", "webtest plan", "E2Eテスト計画", "画面テスト計画", "generate webtest plan", "create test plan from requirements", "webtest計画を更新", "テスト計画の差分更新", "update webtest plan", "画面仕様からテスト更新". dev-planの出力からPlaywright用のWebテスト計画ファイルを自動生成する。画面仕様の変更差分からテスト計画を更新する差分更新モードも対応。
Jest、Vitest、Testing Libraryを使用した包括的なテスト戦略を実装し、モッキング、フィクスチャ、テスト駆動開発を用いたユニットテスト、統合テスト、エンドツーエンドテストを行います。JavaScript/TypeScriptテストの作成、テストインフラの設定、TDD/BDDワークフローの実装時に使用してください。
OpenClawのテストやプラグイン検証の遅さ・メモリ使用量を計測し、読み込みや起動処理の原因を調査。テストの検証範囲を保ちながら改善し、前後の数値を比較します。
This skill should be used when the user asks to "dev-webtest", "Webテスト", "画面の動作確認", "E2Eテスト", "web test", "visual check", "モンキーテスト", "アクセシビリティチェック", "レスポンシブテスト", "フォームテスト". Playwright CLIを使ってWebアプリの動作確認・視覚テスト・アクセシビリティ・レスポンシブ・フォームバリデーションを実行し、問題を検出・記録する。
テスト計画書・テストケース・テストレポートの生成に使用。 「テスト計画を作って」「テストケースを生成して」「E2Eテストを書いて」等で発動。
ISTQB/JSTQB のテストモニタリング&コントロール（test monitoring and control）活動のうち、モニタリングの「基盤構築」を支援するスキル。進捗・カバレッジ・失敗率・flaky 率・成果物トレーサビリティ（リスク→条件カバー率・条件→ケース化率）などのメトリクスを test-plan の完了基準と紐づけて定義し、プロジェクトの CI/ツール構成を調査した上で計測基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援して test-monitoring.md と実装物を作る。「テストのメトリクスを決めたい」「CI でテスト進捗を可視化したい」「カバレッジや失敗率を計測する仕組みを作りたい」「トレーサビリティを継続計測したい」と依頼されたときに使う。**AI が継続的なモニタリングを代行することはしない（計測は基盤が行う）。集まったデータの分析・傾向判断は対象外**。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-monitor <テスト対象名> で明示的に呼び出されたときのみ使用する。
テスト実行時の絞り込み運用ルール。プロジェクト全体テストではなく修正範囲に絞ったテスト実行を行う。`gradlew test`/`pytest`/`jest`/`go test`等のテストランナーを実行するとき、テスト実行コマンドを組み立てるときに必ず参照する。コミット差分や修正ファイルから対象テストを特定する手順を含む。
テスト品質のレビュー（bun:test）。`bun test` の全通過、エンティティのビルダー直接検証と createTestDb による実 SQLite E2E の使い分け、実ネットワーク（JRA）非依存、回帰テストの存在（ImportData の一致条件・枠番の JRA 割当規則・生年計算）、回帰テストの削除/skip 化の禁止、新機能・バグ修正へのテスト追随、契約の検証 vs 実装詳細への過剰結合、console spy と一時ファイルの後始末を検証。Use when user says 'テストレビュー', 'review test', 'テスト品質チェック', or 'カバレッジ確認'.
pytestのマーク体系を設計・実装するスキル。「テストをマークで分類したい」「CIでDockerテストをスキップしたい」「Dockerコンテナ内で実行できないテストを除外したい」「make testでDockerテストを実行したい」「テストの実行対象を環境ごとに切り替えたい」「新しいマークを追加したい」「skipifを使いたい」「pytestの--strict-markersで未定義マークエラーが出る」という依頼で起動。マーク設計→pyproject.toml登録→テストコード付与→CI/ローカルコマンド整合の流れで実装する。
pytest、フィクスチャ、モッキング、テスト駆動開発を使用した包括的なテスト戦略を実装。Pythonテストの記述、テストスイートのセットアップ、テストベストプラクティスの実装時に使用。
ユニットテスト、統合テスト、メインネットフォークを使用してHardhatとFoundryでスマートコントラクトを包括的にテストします。Solidityコントラクトをテストする時、ブロックチェーンテストスイートをセットアップする時、またはDeFiプロトコルを検証する時に使用してください。
PlaywrightとCypressを使用したエンドツーエンドテストをマスターし、バグを捕捉し、信頼性を向上させ、高速デプロイメントを可能にする信頼性の高いテストスイートを構築。E2Eテストの実装、不安定なテストのデバッグ、テスト基準の確立時に使用。
AI QA Agent のメインオーケストレーター。テストスイートまたは個別テストケースの QA を段階的に実行する。フェーズスキルに委譲して段階的開示を行い、サブエージェントでコンテキスト隔離を実現する。「QA」「動作確認」「テストケース実行」「smoke test」「E2E」「手動テスト」「結合テスト」などのキーワードで自動適用。
テスト仕様生成エージェント - AIエージェントがテストコードを実装可能なBDDシナリオ・ユニットテスト・統合テスト仕様を生成。Gherkin形式のシナリオとJUnit/Jest形式のテストケースを策定。/generate-test-specs [対象パス] で呼び出し。
Android アプリ開発 (Kotlin) のテストリファレンス。JUnit4, Espresso, テストピラミッド。 テストダブル, Mockito, MockK, Truth, Robolectric, coroutines/Flow/ViewModel テスト。 AndroidJUnit4, ActivityScenario, FragmentScenario, UiAutomator, AndroidTestOrchestrator。 createComposeRule, Compose UI テスト同期。