Browser Test

フロントエンドとバックエンドの変更が、画面表示・コンソール・API の応答・主要なコンポーネントの挙動に悪影響を与えていないかを、実際のブラウザ（chrome-devtools MCP）で確かめる。
バックエンドの変更も、それを呼ぶ画面を通して確かめる。
実施できる操作は環境ごとの設定に従い、副作用を伴う操作は実施する前にユーザーの承認を得る（設定が無い環境は読み取り専用として扱う）。

使い方

browser-test [--env <環境名>] [--scope <uncommitted|branch|custom>] [--ignore-forbidden-actions]
browser-test setup

• 引数を省くと、環境とスコープをユーザーに確かめる。
  デフォルトは、設定で default とした環境（通常はローカル）と、commit していない差分である。
• --scope custom では、確かめるページと観点をユーザーが自由に指定する。
  指示（例:「設定ページだけ」）が添えられていればそれを対象にし、無ければ実行するときに確かめる。
• --ignore-forbidden-actions は、選んだ環境の forbidden_actions を今回だけ無効にし、該当する操作も確認の対象にする。
  副作用を伴う操作の承認（「厳守の制約」）は、このときも必要である。
• setup は、プロジェクトの設定（環境・起動方法・認証・禁止操作）を対話で確かめて、設定ファイルに記録する（「プロジェクト設定の解決」）。
• 自然文でも発動する。例は「ブラウザで確認」「画面で確認して」「動作確認して」「回帰がないか見て」。

厳守の制約

• 実施できる操作は、選んだ環境の forbidden_actions（「プロジェクト設定の解決」で得る）に従う。
  該当する操作は実行せず、操作の内容をユーザーに伝えて実施を頼む。
• forbidden_actions が定義されていない環境は、読み取り専用として扱う。
  データの作成・変更・削除（CUD）や、課金・生成・通知などの副作用を伴う操作（LLM の起動、メールの送信、外部サービスへの書き込みなど）は実行せず、ユーザーに実施を頼む。
• --ignore-forbidden-actions を指定したときは、forbidden_actions に該当する操作も実施してよい。
• どの場合も、CUD・課金・生成・通知などの副作用を伴う操作は、実施する前に操作の内容と影響を伝えて、ユーザーの承認を得る。
• 環境がどこまで分かれているか（ローカル環境が専用のデータを持つか、リモートの DB や外部 API などの共有のリソースを参照するか）は、プロジェクトごとに違う。
  分かれていることを確かめられない限り、書き込みと課金の操作は共有の環境に影響する前提で承認を求める。
• 呼び出し元のスキルから環境を渡されたときは、渡された環境だけを使う。
  設定ファイル（skills.browser-test.environments）を開かず、存在も確かめず、内容にも触れない。
  「参照していない」ことを示す目的でも読まない。読んだ内容が判断や応答に入り込むのを防ぐためである。
  受け渡しの取り決めは `references/project-config.md` で定義する。

前提

• MCP: chrome-devtools MCP が有効であること。
  主に使うツールは次のとおりである。
  navigate_page・list_pages・list_console_messages・take_snapshot・take_screenshot・wait_for・click・fill・list_network_requests・get_network_request
wait_for は、非同期の描画が終わるのを待つのに使う。
• MCP が無効か未設定のときは、ユーザーに有効にするよう促して、このスキルを中断する。
  中断するときは、環境が整った後に行う確認の内容（対象のページと確認の観点の一覧）を導いて、報告に残してから中断する。
  ローカル環境が起動していないなど、他の理由で中断するときも同じである。
• Google への送信を止めるかは、利用者が MCP の設定で決める。このスキルは引数を求めず、追加も促さない。
  送信について聞かれたら、次の事実と止め方を示す。
  • MCP 自身が利用統計を Google へ送る設定は、デフォルトで有効である。起動引数 --no-usage-statistics で止まる。
    性能のトレース（performance_start_trace など）は、トレースの URL を CrUX API へ送る。--no-performance-crux で止まる
    （出典: https://github.com/ChromeDevTools/chrome-devtools-mcp#usage-statistics）
  • この 2 つの引数では、ブラウザ本体の送信は止まらない。MCP がデフォルトで起動する Google Chrome は、ページを開かなくても、起動の数秒後から Google へ送信する。
    外部への通信を許可制にした環境では、遮断された送信が間隔を広げながら再試行し続ける。
    ブラウザ本体の送信を避けるなら、--executablePath に Playwright の headless shell（chromium_headless_shell-<revision>/.../chrome-headless-shell）を渡す
    （出典: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/configuration.md）。
    MCP が公式に対応するのは Google Chrome と Chrome for Testing なので、headless shell で使うツールは、使う前に 1 度動くことを確かめる。
    revision は Playwright の版ごとに変わるので、playwright-core/browsers.json の chromium-headless-shell の revision から組み立てる
• WSL で実行する場合は、Chrome 本体と CJK フォント（fonts-noto-cjk。日本語の文字化けを防ぐ）が要る。
• ツール: git（確認のスコープを導く）、curl（ローカル環境が動いているかを確かめる）

プロジェクト設定の解決

環境（名前・URL・認証・デフォルト・禁止操作）とローカルの起動方法は、リポジトリごとに違う。
解決の手順（設定ファイル、リポジトリの探索、ユーザーへの確認の順）と、設定ファイル .config/skills/shoji9x9/skills.yml の扱いは `references/project-config.md` にある。
セットアップモード（browser-test setup。この解決を対話で先に行い、設定ファイルに記録する）の手順も同じファイルにある。

フロー

1. 環境とスコープを決める
   • 呼び出し元のスキルから環境を渡されたときは、環境を解決せず（設定ファイルを開かず、存在も確かめず）、渡された環境をそのまま使う（「厳守の制約」）。
   • それ以外のときはプロジェクトの設定を解決する。--env があればその環境を使い、省いたときは環境（デフォルトは設定で default とした環境）をユーザーに確かめる。
   • 確認のスコープは、環境の渡され方に関わらず、--scope があればそれを使い、省いたときはユーザーに確かめる（「使い方」の引数を省いたときと同じ）。
   • 認証が必要な環境では、ユーザーがログインする。「ログインが完了したら教えてください」と伝え、完了の合図を待ってから確認を始める。
2. サーバーが動いているかを確かめる（ローカルを選んだとき）
   • まず、解決した URL（check_urls。省いたときは url）に curl -s -o /dev/null -w "%{http_code}" でつながるかを確かめる。
     動いていれば、pre_commands も start も実行せずに次へ進む。
   • 動いていなければ、確認を始めない。解決した pre_commands（あれば）と起動コマンドをまとめて示し、ユーザーに実行を促す。
     このスキルはこれらを自動で実行しない（build や codegen などの副作用を、承認なしに起こさない）。
   • 起動が終わった合図を受けたら、つながるかをもう一度確かめる。つながらなければ、そこで止まる。
3. 確認のスコープを取得し、影響するページを導く
   • スコープは次の 3 つである。
     • uncommitted（デフォルト）: git status --short・git diff --name-only と untracked のファイル
     • branch: git diff --name-only <ベースブランチ>...HEAD
     • custom: ユーザーが指定したページと観点
   • フロントエンドの変更は、ルーターの定義（React Router の Route の定義、Next.js の pages/・app/ ディレクトリ、Vue Router など）から、変更したファイルをページに対応づける。
     認証のコンテキスト・レイアウト・共有の UI コンポーネント・グローバルな状態など、全体に関わる部分の変更は、すべてのページに影響するとみなす。
     共有のコンポーネントは、grep -rl で import している側を探す。
   • バックエンドの変更は、変更したハンドラやルートが公開する API のパスを特定し、そのパスを呼ぶ画面を grep で探す。
     該当するページで、データの表示が正しいか、空の状態・エラーの表示・型の不一致を確かめる。
     Network 系のツールで、リクエストのステータスとレスポンスの本文も確かめる。
     ただし、副作用を伴う API を承認なしに呼び出さない（「厳守の制約」に従う）。
4. 各ページを確かめる。対象のルートごとに次を行う。
   1. navigate_page で対象の URL を開く。非同期の描画は wait_for で終わるのを待つ。
   2. list_console_messages で error と warn が 0 件であることを確かめる。
      console のメッセージはページを移るたびに消えるので、ページを開いた直後に確かめる。
   3. 必要に応じて、take_snapshot で描画の内容（主要な要素・一覧の件数・見出し）を確かめる。
      snapshot は大きくなることがあるので、大きいときはファイルに保存するオプションを使い、必要な部分だけを読む。
      要素の識別子（uid）はページを描き直すと変わるので、click などの直前に再取得する。
   4. 主要なコンポーネントは、副作用の無い操作を中心に動きを確かめる。副作用を伴う操作は「厳守の制約」に従う。
5. 課題を見つけたら、環境を変えて原因を切り分ける
   • 課題を見つけたら、今回の変更が原因だと決める前に切り分ける。変更を含まない別の環境（デプロイ済みの環境など）で、同じ操作を再現する。
     再現すれば、もともとある課題か環境が原因である可能性が高い。再現しなければ、今回の変更が原因である可能性が高い。
   • デプロイ済みのコードがベースブランチと一致するとは限らない点に注意する。
   • 認証が必要で別の環境で確かめられないときは、ユーザーに頼む。
   • 切り分けの結果（今回の変更が原因、もともとある、環境やデータが原因、切り分けが終わっていない）を報告に書く。
6. 報告する
   • 確認の観点 × 対象のページ × 結果の表にまとめる。確かめたすべてのルートと、console に error と warn が無かったことを書く。
   • 課題は、切り分けの結果と根拠を書く。
   • CUD や課金が必要で実施できなかった確認は、ユーザーに代わりの操作を頼んだ内容として書く。

インタラクションの区分

区分	操作例
副作用なし（承認不要で実施可）	ページ遷移、検索ボックスへの入力、ドロップダウンの開閉、行の展開、タブ切替、フィルタ選択
副作用あり（実施前に承認）	「保存」「実行」「削除」「送信」など書き込み・課金・生成・通知を伴うボタン

副作用のある操作でも、環境の forbidden_actions に該当するものは実施せず、ユーザーに実施を頼む（--ignore-forbidden-actions を指定したときを除く。「厳守の制約」）。

注意

• ページの数や件数の網羅を、head や grep -A N などで一部だけを見た結果を根拠に断定しない。すべてを出力する方法（grep -c・wc -l）で数える。
• console にエラーが無いことと、正しく描画されていることは別である。重要なページは、snapshot で主要な要素があることまで確かめる。