Agent Skills by ALSEL
OpenAIソフトウェア開発⭐ リポ 1品質スコア 63/100

webapp-testing

【テスト】Python Playwrightスクリプトを使用して、個別のページやコンポーネントのテストが必要な場合に使用します。

description の原文を見る

[Testing] Use when you need individual page/component testing with Python Playwright scripts.

SKILL.md 本文

Codex互換性に関する注記:

  • Codexでリポジトリスキルを呼び出す際は $skill-name を使用してください。このミラーコピーはレガシーClaudeの /skill-name 参照を書き直します。
  • このCodexミラーの計画ガイダンスには plan-hard スキルを推奨します。
  • タスクトラッカーの要件: ワークフローやスキルステップを実行する前に、すべてのステップのタスク追跡を作成/更新し、進捗の変化に応じて同期を保ってください。
  • ユーザー質問プロンプトはCodexでユーザーに直接質問することを意図しています。
  • Claudeに特有のモード切り替え指示が表示される場合は無視してください。
  • 厳密な実行契約: ユーザーがスキルを明示的に呼び出した場合、そのスキルプロトコルを記述通りに実行してください。
  • サブエージェント認可: スキルがユーザーから呼び出されるか、AI検出され、そのプロトコルがサブエージェントを必要とする場合、そのスキル起動は当該タスクに必要な spawn_agent サブエージェントの使用を認可します。
  • ユーザーが明示的に偏差を先に承認する場合を除き、プロトコルステップをスキップ、並べ替え、またはマージしないでください。
  • ワークフロースキルの場合は、リストされた各子スキルステップを明示的に実行し、段階的な証拠を報告してください。
  • 必要なステップ/ツールがこの環境で実行できない場合は、適応する前にユーザーに確認して停止してください。
<!-- CODEX:PROJECT-REFERENCE-LOADING:START -->

Codexプロジェクト参照読み込み (フックなし)

Codexはクロード フック ベースのドキュメント注入を受け取りません。 コーディング、計画、デバッグ、テスト、またはレビュー時は、このルーティングを使用して明示的にプロジェクトドキュメントを開いてください。

常に読むこと:

  • docs/project-config.json (プロジェクト固有のパス、コマンド、モジュール、およびワークフロー/テスト設定)
  • docs/project-reference/docs-index-reference.md (完全な docs/project-reference/* カタログへのルート)
  • docs/project-reference/lessons.md (常に有効なガイドラインとアンチパターン)

状況に応じたドキュメント:

  • バックエンド/CQRS/API/ドメイン/エンティティ変更: backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
  • フロントエンド/UI/スタイリング/デザインシステム: frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
  • 仕様/テストケース計画またはTC マッピング: feature-docs-reference.md
  • 統合テスト実装/レビュー: integration-test-reference.md
  • E2Eテスト実装/レビュー: e2e-test-reference.md
  • コードレビュー/監査作業: 変更されたファイルに基づいて code-review-rules.md およびドメインドキュメント

すべてのドキュメントを無分別に読まないでください。docs-index-reference.md から始め、タスクに関連するファイルのみを開いてください。

<!-- CODEX:PROJECT-REFERENCE-LOADING:END -->

クイックサマリー

目標: サーバーのライフサイクル管理を伴うPython Playwrightスクリプトを使用してローカルWebアプリケーションをテストします。

フルサイトQA監査 (アクセシビリティ、パフォーマンス、セキュリティ、SEO) の場合は test-ui を使用してください。

ワークフロー:

  1. アプローチの決定 — 静的HTML (セレクタを直接読み込む) vs 動的アプリ (サーバーヘルパーを使用)
  2. サーバー起動 — 自動サーバーライフサイクル管理のために scripts/with_server.py を使用
  3. 偵察 — 移動、networkidle を待機、スクリーンショット/DOM検査
  4. アクション実行 — 発見されたセレクタを使用してPlaywrightスクリプトを記述

重要なルール:

  • 動的アプリでDOMを検査する前に、常に networkidle を待機してください
  • バンドルされたスクリプトをブラックボックスとして使用し、まず --help を実行して、ソースを読まないでください
  • 常にChromiumをヘッドレスモードで起動し、完了時にブラウザを閉じてください

懐疑的になってください。批判的思考、段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度80%以上が必要です (アイデアは80%以上である必要があります)。

Webアプリケーション テスト

ローカルWebアプリケーションをテストするには、ネイティブPython Playwrightスクリプトを記述します。

利用可能なヘルパースクリプト:

  • scripts/with_server.py - サーバーのライフサイクルを管理 (複数のサーバーをサポート)

常にスクリプトを --help で実行 して使用方法を確認します。カスタマイズされたソリューションが絶対に必要な場合を除き、ソースを読まないでください。これらのスクリプトは非常に大きく、コンテキストウィンドウを汚染する可能性があります。コンテキストウィンドウに取り込まれるべてのスクリプトではなく、ブラックボックススクリプトとして直接呼び出されるために存在します。

決定木: アプローチの選択

ユーザータスク → 静的HTMLですか?
    ├─ はい → セレクタを識別するためにHTMLファイルを直接読む
    │         ├─ 成功 → セレクタを使用してPlaywrightスクリプトを記述
    │         └─ 失敗/不完全 → 動的として扱う (以下)
    │
    └─ いいえ (動的Webアプリ) → サーバーはすでに実行されていますか?
        ├─ いいえ → 実行: python scripts/with_server.py --help
        │           その後、ヘルパーを使用して、簡略化されたPlaywrightスクリプトを記述
        │
        └─ はい → 偵察してからアクション:
            1. 移動してnetworkidleを待機
            2. スクリーンショットを撮るか、DOMを検査
            3. レンダリング状態からセレクタを識別
            4. 発見されたセレクタでアクションを実行

例: with_server.py の使用

サーバーを起動するには、まず --help を実行してから、ヘルパーを使用します:

単一サーバー:

python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py

複数サーバー (例: バックエンド + フロントエンド):

python scripts/with_server.py \
  --server "cd backend && python server.py" --port 3000 \
  --server "cd frontend && npm run dev" --port 5173 \
  -- python your_automation.py

オートメーションスクリプトを作成するには、Playwrightロジックのみを含めます (サーバーは自動的に管理されます):

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True) # 常にchromiumをヘッドレスモードで起動
    page = browser.new_page()
    page.goto('http://localhost:5173') # サーバーはすでに実行中で準備完了
    page.wait_for_load_state('networkidle') # 重要: JSが実行されるのを待つ
    # ... オートメーションロジック
    browser.close()

偵察してからアクションパターン

  1. レンダリングされたDOMを検査:

    page.screenshot(path='/tmp/inspect.png', full_page=True)
content = page.content()
page.locator('button').all()

  2. 検査結果からセレクタを識別

  3. 発見されたセレクタを使用してアクションを実行

一般的な落とし穴

❌ しないこと: 動的アプリで networkidle を待機する前にDOMを検査 ✅ すること: 検査する前に page.wait_for_load_state('networkidle') を待機

ベストプラクティス

  • バンドルされたスクリプトをブラックボックスとして使用 - タスクを達成するには、scripts/ で利用可能なスクリプトのいずれかが役に立つかどうかを検討してください。これらのスクリプトは、コンテキストウィンドウを汚すことなく、一般的で複雑なワークフローを確実に処理します。--help を使用して使用方法を確認し、直接呼び出してください。
  • 同期スクリプトに sync_playwright() を使用
  • 常にブラウザを閉じる
  • わかりやすいセレクタを使用: text=、role=、CSSセレクタ、またはID
  • 適切な待機を追加: page.wait_for_selector() または page.wait_for_timeout()

リファレンスファイル

  • examples/ - 一般的なパターンを示す例:
    • element_discovery.py - ページ上のボタン、リンク、入力の発見
    • static_html_automation.py - ローカルHTMLにfile:// URLを使用
    • console_logging.py - オートメーション中のコンソールログのキャプチャ

[重要] タスク追跡を使用して、開始前にすべての作業を小さなタスクに分割します (各ファイル読み込みのタスクを含む)。これは長いファイルからのコンテキスト損失を防ぎます。単純なタスクでは、AIは ユーザーにスキップするかどうかを注意深く質問する必要があります。

<!-- SYNC:critical-thinking-mindset -->

批判的思考マインドセット — 批判的思考、段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度80%以上が必要です。 ハルシネーション対策: 推測を事実として提示しないでください。すべての主張に対して、ソース、エラーのチェック、独立した相互参照を引用し、自分自身の信頼度に懐疑的になる。証拠のない確実性はすべてのハルシネーションの根源です。

<!-- /SYNC:critical-thinking-mindset --> <!-- SYNC:evidence-based-reasoning -->

証拠ベースの推論 — 推測は禁止されています。すべての主張には証拠が必要です。

  1. すべての主張に対して、file:line、grep結果、またはフレームワークドキュメントを引用してください
  2. 信頼度を宣言: >80%で自由に行動、60-80%で先に確認、<60%では推奨しない
  3. アーキテクチャ変更には クロスサービス検証が必要
  4. 「十分な証拠がない」は有効な出力です

ブロック解除まで: - [ ] 証拠ファイルパス (file:line) - [ ] Grep検索実行 - [ ] 3つ以上の同様のパターン発見 - [ ] 信頼レベル明記

証拠なしで禁止: 「明らかに」、「思う」、「〜べき」、「おそらく」、「これは〜のため」 不完全な場合 → 出力: 「証拠不足。確認済み: [...]. 未確認: [...].」

<!-- /SYNC:evidence-based-reasoning --> <!-- SYNC:ai-mistake-prevention -->

AI誤り防止 — すべてのタスクで避けるべき障害モード:

削除前に下流参照を確認してください。 コンポーネント削除はドキュメントとコードの古さのカスケードを引き起こします。削除前にすべての参照ファイルをマップしてください。 AI生成コンテンツを実際のコードに対して検証してください。 AIはAPI、クラス名、メソッドシグネチャをハルシネートしています。ドキュメント化または参照する前に、grepで存在を確認してください。 編集後に完全な依存関係チェーンを追跡してください。 定義を変更すると、それから派生した下流変数とコンシューマーを見落とします。常に完全なチェーンを追跡してください。 正確性の検証時にすべてのコードパスを追跡してください。 コード存在の確認は実行確認ではありません。常に早期終了、エラー分岐、条件付きスキップを追跡してください。幸せなパスだけではなく。 デバッグ時に「誰の責任か」を先に質問してください。 呼び出し側 (間違ったデータ) またはカリー側 (間違った処理) でバグがあるかを追跡してください。責任レイアーで修正してください。症状サイトにパッチを当てないでください。 既存の値は意図的と仮定する。変更前に理由を聞いてください。 定数、制限、フラグ、またはパターンを変更する前に、コメント、git blame、周囲のコードを読んでください。 最初だけでなく、すべての影響を受ける出力を検証してください。 複数のスタックにタッチする変更には、すべての出力を検証する必要があります。1つのグリーンチェックですべてのグリーンチェックではありません。 全体的優先デバッグ。最も近い注意トラップに抵抗してください。 障害を調査する場合は、最初にすべての前提条件 (設定、環境変数、DB名、エンドポイント、DI登録、データ前提条件) をリストしてから、各前提条件を証拠に対して検証してから、コードレイヤーの仮説を形成してください。 手術的な変更。diff テストを適用してください。 バグ修正: すべての変更行はバグに直接追跡する必要があります。隣接するコードのスタイル変更や改善をしないでください。拡張タスク: 改善を実装してから明示的に発表してください。 曖昧性を無言で選択する前に、コーディングの表面化してください。 リクエストに複数の解釈がある場合は、それぞれ努力見積もりを付けて提示し、質問してください。すべてのレコード、ファイルベース、またはより複雑なパスを静かに仮定しないでください。

<!-- /SYNC:ai-mistake-prevention --> <!-- SYNC:evidence-based-reasoning:reminder -->

重要 注意 すべての主張に対して file:line 証拠を引用 (信頼度>80%で行動)。証拠なしに推測しないでください。

<!-- /SYNC:evidence-based-reasoning:reminder --> <!-- SYNC:critical-thinking-mindset:reminder -->

注意 批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度>80%で行動します。ハルシネーション対策: 推測を事実として提示しないでください。

<!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->

注意 AI誤り防止を適用してください。全体的優先デバッグ、責任レイヤーで修正、コーディング前に曖昧性を表面化、圧縮後にファイルを読み直してください。

<!-- /SYNC:ai-mistake-prevention:reminder -->

終了リマインダー

重要 注意 タスク追跡を使用して小さなtodoタスクに作業を分割してから開始する 重要 注意 新しいコードを作成する前に、コードベース内で3つ以上の同様のパターンを検索する 重要 注意 すべての主張に対して file:line 証拠を引用 (信頼度>80%で行動) 重要 注意 最終的なレビューtodoタスクを追加して、作業品質を検証する 義務 重要 注意 開始前に以下のファイルを読んでください:

重要 注意 開始前に CLAUDE.md を読んでください

[タスク計画] 行動する前に、タスク追跡を使用してタスク範囲を分析し、体系的に小さなtodoタスクとサブタスクに分割してください。

<!-- CODEX:SYNC-PROMPT-PROTOCOLS:START -->

フックレスプロンプトプロトコルミラー (自動同期)

ソース: .claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[ワークフロー実行プロトコル] [ブロッキング] ワークフロー実行プロトコル — 義務 重要 必須 重大。理由なくスキップしないでください。

  1. 検出: プロンプトをワークフローカタログと照合
  2. 分析: 最適一致ワークフローを見つけてカスタムステップ組み合わせがより適切かどうかを評価
  3. 質問 (必須フォーマット): この構造で直接ユーザー質問を使用:
    • 質問: 「どのワークフローをアクティブにしますか?」
    • オプション 1: 「[最適一致ワークフロー] をアクティブに (推奨)」
    • オプション 2: 「カスタムワークフローをアクティブに: [step1 → step2 → ...]」(1行の理由を含める)
  4. アクティブ化 (確認された場合): 標準の場合は $workflow-start <workflowId> を呼び出す。カスタムステップを手動でシーケンス
  5. タスク作成: すべてのワークフローステップのタスク追跡
  6. 実行: 各ステップをシーケンスで実行 [批判的思考マインドセット] 批判的思考、段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度>80%で行動します。 ハルシネーション対策原則: 推測を事実として提示しないでください。すべての主張に対してソースを引用し、不確実性を自由に認め、出力エラーをセルフチェック、独立して相互参照、自分自身の信頼度に懐疑的になる。証拠のない確実性はすべてのハルシネーションの根源です。 AI注意原則 (新近効果): 長いプロンプト/プロトコルの上下の両方に3つの最も重要なルールを入れて、長いコンテキストウィンドウの中で命令遵守が生き残るようにしてください。

学んだ教訓

教訓

[重大] ハードに獲得したプロジェクトデバッグ/アーキテクチャルール。 仮説を形成したりコードを書く前に、注意深く適用する必要があります。

クイックサマリー

目標: 既知の障害パターンの再発を防ぐ。デバッグ、アーキテクチャ、命名、AI オーケストレーション、環境。

トップルール (常に適用):

  • 注意 すべての前提条件 (設定、env、DB名、DI登録) を検証してからコードレイヤー仮説を形成
  • 注意 責任レイヤーで修正。症状サイトに呼び出し元固有の防御コードでパッチを当てないでください
  • 注意 並列async + repo/UoW に ExecuteInjectScopedAsync を使用。ExecuteUowTask を使用しないでください
  • 注意 内容ではなく目的で命名。メンバー追加が強制的に名前変更 = 抽象化破損
  • 注意 各ファイルの後に段階的にサブエージェント結果を永続化。最後にバッチ処理しないでください
  • 注意 Windows bash: Pythonエイリアスを検証 (where python/where py)。python/python3 が解決されると仮定しないでください

デバッグとルート原因推論

  • [2026-04-11] 全体的優先: コードの前に環境を検証。 障害 → すべての前提条件 (設定、env vars、DB名、エンドポイント、DI登録、認証情報、権限、データ前提条件) をリストアップ → 証拠を通じて各検証 (grep/cat/query) してからコードレイヤー仮説を立てる。最悪のウサギの穴: 最も近いレイヤーを掘りながら、バグが別の場所にあります。例: 「同期タイムアウト」のデバッグに何時間も費やした。実際の原因: テストappseettingsが間違ったDBを指しています。最も安いチェックが最初です。
  • [2026-04-01] 修正する前に「誰の責任か?」を質問。 追跡: 呼び出し側でバグ (間違ったデータ) またはカリー側 (間違った処理)? 責任レイヤーで修正。症状サイトにパッチを当てて実際の問題をマスクしないでください。
  • [2026-04-01] エラーサイトではなく、データライフサイクルを追跡。 データを追跡: 作成 → 変換 → 消費。バグは通常、消費された場所ではなく、データが作成された場所です。
  • [2026-04-01] コードは呼び出し元に依存しません。 関数/ハンドラー/コンシューマーは誰が呼び出すかを知りません。コメント/ガード/メッセージはビジネス意図を説明します。特定の呼び出し元 (テスト、シーダー、スクリプト) を参照しないでください。

アーキテクチャ不変式

  • [2026-03-31] ParallelAsync + repo/UoW は ExecuteInjectScopedAsync を使用する必要があります、ExecuteUowTask は使用しないでください。 ExecuteUowTask は新しいUoWを作成しますが、外側のDIスコープを再利用します (同じDbContext)。並列イテレーションが非スレッドセーフなDbContextを共有し、データをサイレントに破損させます。ExecuteInjectScopedAsync は新しいUoW + 新しいDIスコープを作成します (反復ごとに新しいrepo)。
  • [2026-03-31] バスメッセージ命名にはサービス名プレフィックスを含める必要があります。コアサービスは機能イベントを消費しないでください。 プレフィックスはスキーマ所有権を宣言します (AccountUserEntityEventBusMessage = Accountsが所有)。コアサービス (Accounts、Communication) がリーダーです。機能サービス (Growth、Talents) からコアに送信する場合、{CoreServiceName}...RequestBusMessage を使用してください。コアが消費する独自のイベントを定義しないでください。

命名と抽象化

  • [2026-04-12] 内容ではなく目的で命名。「OrXxx」アンチパターン。 HrManagerOrHrOrPayrollHrOperationsPolicy は設定メンバーに名前をつけます。役割を追加 → 名前変更 = 破損した抽象化。ルール: 名前は DOES/GUARDS を表現します。含まれるものではなく。テスト: メンバーの追加/削除が強制的に名前変更? YES = コンテンツ駆動 = 悪い → 目的に名前変更 (例: HrOperationsAccessPolicy)。ニュアンス: 「Or」は行動用語で大丈夫 (FirstOrDefault、SuccessOrThrow)。発生するもの を表現します。メンバーシップではなく。

環境とツール

  • [2026-04-20] Windows bash: python/python3 が解決されると仮定しないでください。エイリアスを先に検証。 Pythonは bash PATH にそれらの名前の下に ない可能性があります。確認: where python / where py。1行、node がJS代替存在の場合は py (Windows Python Launcher) を優先します。

テスト固有の教訓 → docs/project-reference/integration-test-reference.md 学んだ教訓セクション。本番コードアンチパターン → docs/project-reference/backend-patterns-reference.md アンチパターンセクション。一般的なデバッグ/リファクタリングリマインダー → .claude/hooks/lib/prompt-injections.cjs でシステム教訓。

終了リマインダー

  • 重要 注意 全体的優先: コードレイヤー仮説の前にすべての前提条件 (設定、env、DB名、エ

ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
duc01226
リポジトリ
duc01226/easy-claude
ライセンス
Apache-2.0
最終更新
2026/5/10
GitHubで原本を見る →フィードバックを送る

Source: https://github.com/duc01226/easy-claude / ライセンス: Apache-2.0

本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: duc01226 · duc01226/easy-claude · ライセンス: Apache-2.0