インストール
npx skills add https://github.com/currents-dev/playwright-best-practices-skill向いている人
TypeScript で Playwright テストを書き、デバッグし、保守しており、エージェントに今の活動向けの助言を出してほしい人向け。公式は活動駆動：何をしているかが対応参照を指し、全部を一度に読み込まない。
リポジトリ：
https://github.com/currents-dev/playwright-best-practices-skill
リポジトリにすでに Playwright テストがあり、不安定なケースを直す、またはアクセシビリティ検査を足すときに向く。材料はスキル名や “Playwright best practices” を口にしなくてよいと書く。作業をはっきり述べれば足りる。
主に他言語のテストを書く環境、または互換のスキル導入機構がない環境には向かない。既存材料の指導範囲は TypeScript の Playwright テスト。書いていない言語へ広げない。
3分で最初の試行を終える
公式推奨の経路はこの1本だけ。
前提条件：このマシンで npx を実行でき、今のエージェントがこの導入方式に対応し、ワークスペースに議論できる Playwright テストがある。導入前に、書き込む先が実際に使っているエージェント環境だと確認する。
導入先は npx skills add が処理する。材料に目標フォルダはない。出ていないパスを手で足さない。
コピーして実行：
npx skills add https://github.com/currents-dev/playwright-best-practices-skill
成功の合図：コマンドが正常終了する。先に読み取り検査。ログイン関連テストを開き、エージェントへ「この不安定なログインテストを見て、まず原因候補を示せ。ファイルは変えるな」。公式例はまさに “fix this flaky login test”。返信が具体的な待ち、狙い、アサーションの問題に触れ、空疎な書き直しでなければ、対応参照が使われた。
分析を受け入れたあと、どのファイルを変えてよいか明示して許可する。テスト変更は副作用がある。範囲確認前にパッチさせない。
使用例
事例1：不安定なログインテストを調べる。公式例は “fix this flaky login test”。時々通り時々落ちるテストで、先に焦点の定まった助言が欲しいとき。現象と失敗ログを述べ、分析だけ求める。成功時、返信は今の活動の参照に着地し、57 本全部を一度に出さない。8分類の名前は材料にない。分類名や文書ファイル名を捏造しない。本当に直す前に、動かすファイルと期待動作を確認する。
事例2：アクセシビリティテストを足す。公式例は “add accessibility tests”。ページ流れが既にあり、アクセシビリティ検査を足したいとき。先に今のページテストから提案アサーションを出させ、まだファイルは書かない。セレクタと範囲を確認してからケースを足させる。成功の合図は、指定ページに対応する助言であり汎用雛形ではない。既存材料はこの作業記述で起動できることだけ示す。具体 API や設定キーは展開していない。
利用の境界
既存材料が示すのはインストールコマンド1本と「活動に応じて参照を指す」使い方。出ていない市場コマンド、クローン経路、他インストーラに切り替えない。必須クライアントも名指ししていない。特定エージェントの独占対応と書かない。
参照庫は 57 本、8 類。分類名と各文書パスは未記載。文書パスやスキル下位ディレクトリを発明しない。
指導対象は TypeScript での Playwright テストの執筆、デバッグ、保守。他言語や他テスト枠の手順は既存材料から補えない。テスト変更はリポジトリを変える。先に分析、それから書き込みを許可。詳細は公式リポジトリ：
https://github.com/currents-dev/playwright-best-practices-skill