「テスト」の検索結果

E2E テストの spec を書く・編集する・レビューする際に必ず発火させる。新しいシナリオの追加、既存 E2E テストの修正・デバッグ、E2E テストの書き方の相談、slice-tdd skill から E2E spec が必要と判断された場面で使う。触る範囲に対応するプロジェクトの E2E の流儀 (spec の書き方・構造・命名) を探して従わせる入口。E2E を実行する手順は扱わない (別スキルの責務)。

テストピラミッド・テスト設計・品質戦略を整理する判断軸。テストの粒度・スコープ・優先順位に迷ったときに使う。TDDの具体的な実装手順は developer-specialist と併用する。

テスト品質を動作カバレッジの観点から分析し、クリティカルなテストギャップを特定する。テストファイルの追加・変更時に使用。

Use this skill when writing unit tests, mocking dependencies, testing pure functions, or measuring coverage with Vitest. Trigger words: ユニットテスト, 単体テスト, Vitest, モック, テストを書く, カバレッジ, describe, it, expect, vi.mock.

QA テスト結果を集約し、構造化レポートを生成するフェーズスキル。失敗テストの分析と次のアクション提案を含む。「QA レポート」「テスト結果」「QA 結果」などのキーワードで自動適用。

QA テストスイートの解析・前提条件解決・実行計画策定を行うフェーズスキル。ios-qa-workflow から参照される。「テスト計画」「QA 準備」「テストスイート解析」などのキーワードで自動適用。

仕様（チケットの完了条件・受入基準）からE2Eテストを実装する（非対話）。Triggers on: '/create-e2e', 'E2Eテストを書いて', 'E2Eテストを追加して'

テストが担保していない公開面（GAP）を検出する。報告のみで、ファイル生成・修正・Issue 起票はしない。Triggers on: '/surface-audit', 'テスト担保を診断', '公開面を監査', 'GAPを検出', 'テストの無い公開面'

テスト観点のレビューエージェント。 テスト網羅性、命名規則、フレーキーテスト、カバレッジギャップの個別スキルへルーティングする。

重要: ユーザーがAndroidテスト実行をリクエストした場合、常にこのスキルを最初に使用してください。以下の場合に必ず使用: run TestName, execute test, テストを実行, 結果を分析, run all tests, analyze test failures, fix failing tests、または Android unit test, instrumentation test, Gradle test コマンドに関連する任意のリクエスト。./gradlew test や Bash コマンドを直接使用しないでください - 常にこのスキルに委譲してください。Multi-variantプロジェクト、JAVA_HOME セットアップ、一般的なテストパターンに対応しています。

開発修正・機能実装後の動作確認→スクショ撮影→テストチェックリスト→修正報告書（md+PDF）作成の一連のワークフロー。 Use when: 「動作確認して」「スクショ撮って」「テスト結果まとめて」「修正報告書作って」「確認してPDFで送って」等の依頼。 開発作業後のブラウザ確認、スクリーンショット収集、テスト結果の文書化、PDF報告書生成に使用。 Don't use when: コードの実装のみ（動作確認・報告書が不要な場合）。デザインレビュー（実装の動作確認ではない場合）。

chrome-devtools を使って動作確認チェックリストに沿ったテストを実行する。「動作確認して」「テストして」「動作テストして」「ブラウザで確認して」「チェックリストを確認して」などの依頼で発火する。

agent-browser CLIでブラウザ検証をサブエージェント実行。 E2Eテスト、UI確認、フォーム検証、スクリーンショット取得に使用。 Trigger: agent-browser, ブラウザで確認, ブラウザ検証, E2E確認, UIテスト, スクリーンショット撮って, 画面確認, ブラウザテスト

Kotest、MockK、コルーチンテスト、プロパティベーステスト、Koverカバレッジを含むKotlinテストパターン。イディオマティックなKotlinプラクティスによるTDD方法論に従う。

テストの追加・修正・削除、または実装後の検証方針を判断するときに使う。タスクごとに反射的な回帰テストを増やさず、守るべき仕様、不安な仕様、実際に使われる経路、事前条件と事後条件を中心にテストを設計するためのスキル。

OpenClaw Control UIの画面変更を、状態別の比較ギャラリーと実ブラウザの操作テストで確認し、利用者のコメントや変更前後の画像を残すスキル。

• 読み込み・空・エラー状態の比較
• 画面変更への意見を集めたいとき
• 模擬Gatewayでチャット操作を検証

OpenClawのチャット接続を設定し、実際のテスト送信で届くか確認します。トークンを露出させず、既存のアクセス制限を守りながら接続の問題も調べます。

• Telegramのボットを接続したいとき
• テストメッセージの到着確認
• チャット接続の不具合調査

OpenClawのQAシナリオを模擬環境や実サービスで実行し、失敗原因の修正、結果レポートの確認、複数モデルの応答スタイル比較まで支援するスキル。

• 模擬環境や実サービスでQAを実行
• 失敗シナリオの原因調査と再検証
• 複数モデルのキャラクター比較

OpenClaw全体の品質検証を継続し、不具合の再現から根本原因の修正、レビュー、反映確認まで進めます。実環境や負荷の検証結果を、再開可能な報告書に記録します。

• OpenClawの複数領域の不具合調査
• 回帰テストと独立レビューで修正を検証
• 実接続・UI・配布物の動作確認

Unity カジュアルゲームを仕様駆動開発（Specification-Driven Development）で作成する。仕様を先に確定させ、設計・実装・テストを行うことで手戻りを最小化する。「ゲームを作って」「仕様駆動開発」「SDD」「ゲーム企画書」「機能仕様書」「技術仕様書」「テスト仕様書」「タスクリスト」「Unityゲーム開発」「カジュアルゲーム」といったリクエスト時に使用。Phase 1（企画書）からPhase 8（リリース）まで段階的にドキュメントを作成し、仕様に基づいて実装・テスト・検証を行う。

変更差分から重要なテスト観点と欠落を洗い出し、優先度付きでテストケース案を提示する

Telegramのテスト環境で実ユーザーとしてOpenClawを操作し、応答や編集・削除・リアクションなどを記録して、利用者に見える動作を検証するスキル。

• DMの応答やコマンドを検証したいとき
• グループのメンションやトピックの検証
• 編集・削除・入力中表示の動作確認

Pythonの実行を途中で止めて変数や処理の流れを調べ、例外発生時の状態や稼働中のプロセスも確認しながら、不具合の原因を追うスキル。

• 失敗するPythonテストの変数確認
• 予想外の状態変化を追いたいとき
• 例外発生時の状態を調べたいとき

Node.jsの処理を途中で止め、変数や実行経路を調べるスキル。非同期処理の停止、不安定なテスト、メモリ増加、CPU負荷の原因調査に使えます。

• 非同期処理が止まる原因を調べたいとき
• 時々失敗するテストを調べたいとき
• 起動時や子プロセスの不具合調査