ui-test-playwright

Playwright UI 自動化テスト

英語版： 対応する英語版スキルを参照してください。

使用する場面

• Playwright UI 自動化テストのワークフローを対象としたテスト計画や自動化設計を出力する必要がある場合。
• プロジェクトですでに関連ツールを使用している、またはすぐに導入できるツール固有の計画が必要な場合。

出力形式のオプション

デフォルトでは Markdown を使用します。明示的に別の形式が求められていない限り、出力形式を追加しないでください。

使用方法

1. prompts/ui-test-playwright.md を開き、メインプロンプトとして使用します。
2. 実際のプロジェクトのコンテキスト（範囲、環境、制約、リスク、依存関係、期待する成果物）を補足します。
3. 入力が不完全な場合は、まず使用可能な初版を返し、不足情報と仮定を明記します。

参考ファイル

• ドメイン上の結果、正しい対照、または証拠の不足を検証する際は、references/domain-decision-example.md の匿名化された入力、項目ごとの期待結果、再計算の根拠を参照してください。

• prompts/ui-test-playwright.md：このスキルのメインプロンプト。

• references/framework-spec.md：ツール固有の構成とカバレッジの説明。

• references/setup-and-ci.md：インストール、実行、CI の説明。

• examples/sample-context.md：リクエストコンテキストの例。

• scripts/run-tests.sh：軽量なローカル実行用エントリーポイント。

ドメイン固有の実行上の要点

1. プロジェクトの Playwright／Node／browser のバージョン、projects／fixtures、設定を固定します。実際のエントリーポイントを使用し、テスト ID、commit、worker／project、環境を記録します。互換性のない設定は、フレームワークを勝手に変更せず、まず診断します。
2. role／name／testid など、安定したセマンティックロケーターを優先します。実行後は auto-retrying assertion で注文／会計／状態と対象を確認します。ページタイトル／URL は該当するナビゲーション要件を満たすだけであり、支払い成功の代わりにはなりません。
3. 各 worker で、browser context、storage state／アカウント、ビジネスキーを個別に用意し、競合するデータの共有を禁止します。同一ブラウザー内の別 context であっても、サーバー側のアカウント分離を確認し、teardown では依存関係と逆の順序でクリーンアップします。
4. 誤ったビジネス状態と並列の A／B 対照を使って、アサーションの感度を検証します。失敗時は trace／screenshot／ログと、0 以外の runner／CI 終了コードを保持し、最初の失敗は retry 後も確認できるようにします。生成されたアセット、実際の browser 実行、ビジネス上の受け入れ結果は、それぞれ個別に報告します。

よくある誤り

• 範囲が曖昧でコンテキストが不足しているのに、一般論だけの計画をすぐ提示しないでください。
• すべてのモジュールやシナリオを同じ重要度として扱わないでください。
• 仮定と不足情報の説明を省略しないでください。

ベストプラクティス

• prompt ファイルから始め、結果に本当に影響するコンテキストだけを補足します。

• リスクを重視し、すぐに実行またはレビューできる出力にします。

• 情報が不完全な場合は、まず使用可能なバージョンを提示し、そのうえで不足事項を明記します。

• 生成されたアセットのビジネスアサーション、失敗の伝播、または分離を検証する際は、evals/fixtures/checkout-app/README.md を参照し、ローカルの good／bug／timeout 対照を使用します。実行するのは、明示的に実行が指示された場合に限ります。