npx claudepluginhub classmethod/tsumiki --plugin tsumikiThis skill uses the workspace's default tool permissions.
Playwright CLI (`@playwright/cli`) を使ったWebアプリケーションの動作確認・視覚テスト・記録スキル。計画テスト、モンキーテスト、視覚チェック、アクセシビリティ、レスポンシブ、フォームバリデーションの6種類のテストを実行し、検出した問題をエラーディレクトリに記録する。修正は dev-debug 等の別スキルに委譲する。
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Playwright CLI (@playwright/cli) を使ったWebアプリケーションの動作確認・視覚テスト・記録スキル。計画テスト、モンキーテスト、視覚チェック、アクセシビリティ、レスポンシブ、フォームバリデーションの6種類のテストを実行し、検出した問題をエラーディレクトリに記録する。修正は dev-debug 等の別スキルに委譲する。
dev-context → dev-plan → dev-impl → dev-verify
↓
[dev-webtest]
↓
dev-debug (問題修正)
dev-verify でユニットテスト/ビルド/Lintが通った後にWeb画面の動作確認として使用する。単独での使用も可能。
| モード | 引数 | 用途 |
|---|---|---|
| 計画テスト | <plan-name> [--parallel N] | Markdownテスト計画に沿って自動テスト |
| モンキーテスト | monkey <url> | ランダム操作でエラー・崩れを検出 |
| クイックチェック | check <url> | 単一ページの視覚・アクセシビリティ確認 |
| プラン選択 | (引数なし) | 利用可能なプラン一覧から選択して実行 |
| 再テスト | retest | 未解決エラーの再現手順を再実行し、修正済みなら fixed に更新 |
| オプション | デフォルト | 説明 |
|---|---|---|
--parallel N | 2 | シナリオグループの最大並列実行数(1〜5) |
--parallel 1 で従来通りの完全直列実行group フィールドに基づいてグループ化し、異なるグループを並列実行するdepends 順に直列実行する@playwright/mcp) — CLI が利用できない場合のフォールバック。MCP プロトコル経由でブラウザ操作(詳細は references/mcp-workflow.md)Step 1 開始
|
[1-0] docs/dev/webtests/env-knowledge.md を Read(存在する場合)
| → 過去のトラブルシュートを把握し、同じ問題発生時に即座に適用する
|
[1-1] docker compose ps
|
+-- Playwright コンテナ Running --> [1-5] CLI動作確認・モード判定
|
+-- 未起動 / docker compose 自体が使えない
|
[1-2] docker-compose.yaml の存在 + playwright サービスの定義を確認
|
+-- yaml あり & playwright サービス定義済み → AskUserQuestion (A0, C, D)
+-- yaml あり & playwright サービス未定義 → AskUserQuestion (A1, C, D)
+-- yaml なし → AskUserQuestion (B, C, D)
1-0. 過去の環境セットアップ知見を読み込む
docs/dev/webtests/env-knowledge.md が存在する場合、Read して内容を把握する。過去のトラブルシュートを参考に、同じ問題が起きた場合は記録済みの解決策を即座に適用する。
1-1. Docker Compose の状態を確認する
docker compose ps
Playwright コンテナが Running なら 1-5 へ進む。未起動またはコマンド自体が使えない場合は 1-2 へ。
1-2. docker-compose.yaml の存在と playwright サービスの定義を確認する
確認結果に応じて AskUserQuestion で環境セットアップ方法を選択してもらう。各状況で Recommended 付きの選択肢1つ + C + D の3択 になる。
| 選択肢 | 表示条件 | 処理 |
|---|---|---|
| A0) Playwright コンテナを起動する (Recommended) | yaml あり & playwright 定義済み | docker compose up -d playwright → npm install -g @playwright/cli@latest → 1-5 へ |
| A1) 既存の docker-compose.yaml に Playwright サービスを追加する (Recommended) | yaml あり & playwright 未定義 | docker-setup.md を参照して yaml 編集 → docker compose up -d playwright → npm install -g @playwright/cli@latest → 1-5 へ |
| B) 新しい docker-compose.yaml を作成する (Recommended) | yaml なし | docker-setup.md を参照して yaml 新規作成 → docker compose up -d playwright → npm install -g @playwright/cli@latest → 1-5 へ |
| C) 手動でセットアップする | 常に表示 | docker-setup.md を案内 → ユーザーに完了確認 → 1-5 へ |
| D) Docker を使わずローカル MCP で実行する | 常に表示 | docker-setup.md の「ローカル MCP セットアップ」を参照して .mcp.json に playwright 設定追加 → mkdir -p tmp/webtest/screenshots → .gitignore 追記 → MCP モード確定 → Step 2 へ |
※ A0/A1/B は排他(状況に応じて1つだけ表示)。
1-5. CLI 動作確認・モード判定(A0/A1/B/C 選択時のみ)
docker compose exec playwright playwright-cli --version
references/mcp-workflow.md の手順に従う)1-6. 環境セットアップ知見を記録する
Step 1 完了時に docs/dev/webtests/env-knowledge.md に今回の知見を追記する。
env-knowledge.md フォーマット:
# Webtest 環境セットアップ知見
## 成功手順
### <YYYY-MM-DD> <モード名>モード確立
- <実行した手順の要約>
- 所要ステップ: <通過したステップ>
## トラブルシュート
### <YYYY-MM-DD> <問題の概要>
- 症状: <エラーメッセージや観察された挙動>
- 原因: <特定された原因>
- 解決: <実行した解決策>
引数に応じてテストモードを切り替える。
引数解析フロー:
引数あり?
+-- "retest" → 2d へ
+-- "monkey <url>" → 2b へ
+-- "check <url>" → 2c へ
+-- その他の文字列 → plan-name として解釈 → プラン解決へ
+-- 引数なし → プラン一覧表示へ
--parallel N が含まれる場合:
→ N を抽出し maxParallel に設定(デフォルト: 2、範囲: 1〜5)
→ --parallel 部分を引数から除去して上記フローを継続
プラン解決:
docs/dev/webtests/plans/ ディレクトリを Glob で走査し、利用可能な .md ファイルを一覧取得するdocs/dev/webtests/plans/<plan-name>.md が存在する → 2a へ進むdocs/dev/webtests/plans/ にテスト計画がありません。dev-webtest-plan でテスト計画を生成するか、monkey <url> または check <url> で直接テストしてください」と案内するdocs/dev/webtests/plans/<plan-name>.md を読み込むreferences/test-plan-template.md を参照status → in_progresslast-run → 当日の日付(YYYY-MM-DD)mkdir -p tmp/webtest/results/<plan-name> で中間結果ディレクトリを作成する
4-1. APIデータセットアップの実行(「## APIデータセットアップ」セクションが存在する場合):テスト計画の「### ファイル共通」セクション内の curl コマンドを上から順に Docker コンテナ内で実行する:
docker compose exec playwright bash -c '<curl コマンド>'
${TOKEN} 等に展開するtmp/webtest/results/<plan-name>/api-setup.md に記録する「### シナリオN固有」セクションの内容をパースし、シナリオ名と curl コマンドの対応を記録する。実際の実行は各シナリオの直前に行う(Step 5-3 の Agent 委譲時にシナリオ固有セットアップも渡す)。
シナリオの group フィールドに基づいてグループ分けする:
group が同じシナリオは同一グループ(グループ内は depends 順に直列実行)group が未指定のシナリオはそれぞれ独立グループとして扱う(他と並列実行可能)depends が未指定のシナリオはグループ内の記述順に実行する例: 4シナリオ(group: auth×2, group: products×1, group未指定×1)
→ グループ: [auth], [products], [シナリオ4]
→ maxParallel=2 の場合: [auth] と [products] を並列 → 完了後 [シナリオ4]
maxParallel(デフォルト: 2)に基づき、同時実行するグループ数を制限するrun_in_background: true)し、完了通知を受けたら次のグループの Agent を起動するmaxParallel: 1 の場合は従来通りの完全直列実行となる1グループにつき1つの Agent を起動する。Agent にはグループ内の全シナリオを渡し、グループ内のシナリオは depends 順に直列実行 させる:
${TOKEN} 等の値)tmp/webtest/results/<plan-name>/<scenario-index>-<scenario-name>.mddocs/dev/webtests/errors/docker compose exec playwright bash -c '<curl コマンド>'
${TOKEN} 等のプレースホルダはファイル共通セットアップで取得した値に展開するskipped として結果に記録する(次のシナリオに進む)
a. シナリオの手順を実行(Step 2a 操作)
b. Step 3 + Step 4: 視覚チェック + アクセシビリティチェック(同時実行可能 — どちらも読み取り専用のため。snapshot を取得した時点で Step 3 は screenshot を Read して判定、Step 4 は snapshot を分析。ただし Tab キーボードテストは Step 3 完了後に実行する)
c. Step 5: レスポンシブテスト(viewport 変更を伴うため単独実行)
d. Step 6: フォームバリデーションテスト(ページ状態を変更するため最後に実行)
e. 問題検出時は error.md を作成
f. 結果を scenario 中間ファイルに書き出す(フォーマットは後述)全グループ完了後、APIクリーンアップを実行する(「## APIクリーンアップ」セクションが存在する場合):
テスト計画の「## APIクリーンアップ」セクション内の curl コマンドを上から順に Docker コンテナ内で実行する:
docker compose exec playwright bash -c '<curl コマンド>'
${TOKEN} / ${ADMIN_TOKEN} 等のプレースホルダはセットアップ時に取得した値に展開するtmp/webtest/results/<plan-name>/api-cleanup.md に記録するテスト計画ファイルの frontmatter status を更新する:
status: donestatus: in_progressStep 7 → Step 8 に進む
Agent が tmp/webtest/results/<plan-name>/<scenario-index>-<scenario-name>.md に書き出す:
---
scenario: "<シナリオ名>"
url: "<テスト対象URL>"
result: passed | failed | skipped
---
## APIセットアップ: <成功/失敗/なし>
- <セットアップの実行結果(1行。なしの場合は「シナリオ固有セットアップなし」)>
## シナリオ結果: <passed/failed/skipped>
- <結果の要約(1-2行)>
## 視覚チェック: <判定>
- <所見(1-2行)>
## アクセシビリティ: <判定>
- 画像alt: <判定> (N/M)
- フォームラベル: <判定> (N/M)
- Heading階層: <判定>
- キーボード: <判定> Tab到達率 N% (N/M)
- ARIA: <判定>
- ランドマーク: <判定>
## レスポンシブ: <判定>
- mobile: <判定> <所見>
- tablet: <判定> <所見>
- desktop: <判定> <所見>
## フォームバリデーション: <判定>
- <パターン>: <判定> | ...
## 検出エラー
- <error.md へのパス>(エラーがない場合は「なし」)
snapshot でページ構造を把握するsnapshot でページ状態を取得console でJavaScriptエラーを確認network でHTTPエラー(4xx/5xx)を確認screenshot を取得するdocs/dev/webtests/errors/<YYYY-MM-DD>-<NNN>-<概要>/error.md を作成tmp/webtest/errors/<YYYY-MM-DD>-<NNN>-<概要>/screenshot.png にスクリーンショットを保存screenshot + snapshot を取得するdocs/dev/webtests/errors/ の未解決エラーについて、再現手順を再実行して修正を確認する。
docs/dev/webtests/errors/ を Glob で走査し、全 error.md を取得するstatus: open のものだけ収集するurl にアクセスする
b. 「再現手順」に記載された操作を Playwright で実行する
c. 「期待される状態」と実際の状態を比較する
d. 判定:
status を open → fixed に更新し、fixedDate: YYYY-MM-DD を追記するstatus: open のまま維持するスクリーンショットを Read tool で読み取り、Claude が視覚的に判断する。判定完了後は画像の内容をテキスト要約に変換し、以降はテキスト要約のみ保持する(画像データはコンテキストから自然に流れる)。
チェック項目(詳細は references/visual-check-criteria.md 参照):
判定:
エラー記録: ⚠️ または ❌ 判定時はエラーディレクトリを作成する:
docs/dev/webtests/errors/<YYYY-MM-DD>-<NNN>-<概要>/error.md を作成tmp/webtest/errors/<YYYY-MM-DD>-<NNN>-<概要>/screenshot.png にスクリーンショットを保存snapshot のアクセシビリティツリーを分析する(詳細は references/accessibility-checklist.md 参照):
img 要素の alt 属性の有無form 要素と label の紐づけpress Tab で確認Chrome DevTools MCP が利用可能な場合は lighthouse_audit でスコアを取得する。
エラー記録: 問題検出時はエラーディレクトリを作成する:
docs/dev/webtests/errors/<YYYY-MM-DD>-<NNN>-<概要>/error.md を作成tmp/webtest/errors/<YYYY-MM-DD>-<NNN>-<概要>/screenshot.png にスクリーンショットを保存シナリオのURLについて3つのビューポートでスクリーンショットを取得し、AIで確認する。判定完了後は画像の内容をテキスト要約に変換し、以降はテキスト要約のみ保持する:
# モバイル
docker compose exec playwright playwright-cli open <url> --headless --viewport 375x667
docker compose exec playwright playwright-cli screenshot --filename=/work/tmp/webtest/screenshots/mobile.png
# タブレット
docker compose exec playwright playwright-cli open <url> --headless --viewport 768x1024
docker compose exec playwright playwright-cli screenshot --filename=/work/tmp/webtest/screenshots/tablet.png
# デスクトップ
docker compose exec playwright playwright-cli open <url> --headless --viewport 1280x800
docker compose exec playwright playwright-cli screenshot --filename=/work/tmp/webtest/screenshots/desktop.png
確認項目:
エラー記録: 問題検出時はエラーディレクトリを作成する:
docs/dev/webtests/errors/<YYYY-MM-DD>-<NNN>-<概要>/error.md を作成tmp/webtest/errors/<YYYY-MM-DD>-<NNN>-<概要>/screenshot.png にスクリーンショットを保存ページ内のフォームを snapshot から自動検出し、以下のパターンでテストする:
| パターン | 入力値 | 期待 |
|---|---|---|
| 空送信 | 全フィールド空 | バリデーションエラー |
| 必須チェック | 必須フィールドのみ空 | 該当フィールドにエラー |
| 型チェック | email欄に非email文字列 | 型エラー表示 |
| 最大長 | 1000文字の文字列 | 切り詰めまたはエラー |
| XSS | <script>alert(1)</script> | スクリプトが実行されない |
| SQLi | '; DROP TABLE users; -- | SQLエラーが発生しない |
| 正常値 | 適切な値 | 成功 |
セキュリティ上の問題(XSS, SQLi)は ❌ として即時報告する。
エラー記録: 問題検出時はエラーディレクトリを作成する:
docs/dev/webtests/errors/<YYYY-MM-DD>-<NNN>-<概要>/error.md を作成tmp/webtest/errors/<YYYY-MM-DD>-<NNN>-<概要>/screenshot.png にスクリーンショットを保存検出された問題は docs/dev/webtests/errors/ に error.md として記録済みである。
error.md の status フィールドを open → fixed に更新して対応状況を管理する計画テスト・モンキーテストの場合、docs/dev/webtests/reports/YYYY-MM-DD-<plan-name>.md にレポートを出力する。
計画テストの場合(サブAgent結果を集約):
tmp/webtest/results/<plan-name>/ 配下の全 scenario 中間ファイルを Read するrm -rf tmp/webtest/results/<plan-name>/ で中間ファイルを削除するレポートには以下を含める:
api-setup.md から集約)api-cleanup.md から集約)サブAgent内でのコンテキスト蓄積を抑制するため、以下のルールを遵守する。
snapshot の取り扱い:
screenshot の取り扱い:
browser_take_screenshot の base64 が直接返るため、判定後すぐにテキスト要約に変換して以降は要約のみ使用するscenario 中間ファイル:
tmp/webtest/results/<plan-name>/ にファイルとして書き出すtmp/webtest/screenshots/ に保存する(git管理しない)docs/dev/webtests/errors/<YYYY-MM-DD>-<NNN>-<概要>/error.md を作成するtmp/webtest/errors/<YYYY-MM-DD>-<NNN>-<概要>/screenshot.png に保存する(git管理しない)docker compose exec playwright 経由で実行するreferences/playwright-cli-reference.md を参照する@playwright/cli が利用できない場合は references/mcp-workflow.md に従って MCP モードで実行する$(git rev-parse --show-toplevel) でルートを取得)---
severity: critical | major | minor
step: "2a-scenario | 2b-monkey | 3-visual | 4-a11y | 5-responsive | 6-form"
status: open | fixed
detected: YYYY-MM-DD
fixedDate:
scenario: "シナリオ名またはテスト概要"
url: "テスト対象URL"
---
## 検出内容
(何が問題だったかの説明)
## 再現手順
1. (手順1)
2. (手順2)
3. ...
## 期待される状態
(正しい動作の説明)
## スクリーンショット

references/playwright-cli-reference.md — Playwright CLI コマンド一覧と使用例references/test-plan-template.md — テスト計画の書き方テンプレートreferences/visual-check-criteria.md — 視覚チェックの判定基準と具体例references/accessibility-checklist.md — アクセシビリティチェック項目の詳細references/docker-setup.md — Docker環境のセットアップ手順references/mcp-workflow.md — MCP モードのワークフローとツール対応表examples/sample-test-plan.md — サンプルテスト計画(Go+Echo+templアプリ向け)