Browser test

Browser Test

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

使い方

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

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

厳守の制約

• 実施できる操作は、選択した環境の forbidden_actions（「プロジェクト設定の解決」で得る）に従う。該当する操作は実行せず、操作内容をユーザーに伝えて実施を依頼する
• forbidden_actions が未定義の環境は読み取り専用として扱う。データの作成・変更・削除（CUD）や課金・生成・通知など副作用を伴う操作（LLM 起動、メール送信、外部サービスへの書き込み等）は実行せず、ユーザーに実施を依頼する
• --ignore-forbidden-actions 指定時は forbidden_actions に該当する操作も実施してよい
• いずれの場合も、CUD・課金・生成・通知など副作用を伴う操作は、実施前に操作内容と影響を伝えてユーザーの承認を得る（注意喚起）
• 環境の分離度（ローカル環境が専用データを持つか、共有リソース〈リモート DB・外部 API 等〉を参照するか）はプロジェクトごとに異なる。分離を確認できない限り、書き込み・課金操作は共有環境に影響する前提で承認を求める

前提

• 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 が無効・未設定のときはユーザーに有効化を促し、本スキルを中断する
• WSL で実行する場合: Chrome 本体と CJK フォント（fonts-noto-cjk。日本語の文字化け防止）
• ツール: git（確認スコープの導出）、curl（ローカル環境の稼働確認）

プロジェクト設定の解決

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

フロー

1. 環境とスコープの確定: プロジェクト設定を解決し、環境（既定は設定で default とされた環境）と確認スコープをユーザーに確認する。認証が必要な環境はユーザーがログインを実施する。「ログインが完了したら教えてください」と伝え、完了の合図を待ってから確認を始める
2. サーバ稼働確認（ローカル選択時）: 解決した URL 群に curl -s -o /dev/null -w "%{http_code}" で疎通確認する。落ちていれば確認を始めず、解決済みの起動コマンドを提示してユーザーに起動を促す
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 がゼロであることを確認する。console メッセージはナビゲーションごとにリセットされるため、ページを開いた直後に確認する
   3. 必要に応じて take_snapshot で描画内容（主要要素・一覧件数・見出し）を確認する。snapshot は巨大化しうるため、大きい場合はファイル保存オプションを使い必要部分のみ読む。要素識別子（uid）はページ再描画で変わるため、click 等の直前に取り直す
   4. 主要コンポーネントは副作用のないインタラクションを中心に動作確認する。副作用を伴う操作は「厳守の制約」に従う
5. 課題発見時のクロス環境切り分け: 課題を見つけたら今回の変更起因かを確定する前に切り分ける。変更を含まない別環境（デプロイ済み環境等）で同じ操作を再現する。再現すれば既存・環境起因の可能性が高く、再現しなければ今回の変更起因の可能性が高い。デプロイ済みコードがベースブランチと一致するとは限らない点、認証が必要でクロス確認できない場合はユーザーに依頼する点、切り分け結果（今回の変更起因／既存／環境・データ起因／切り分け未完）を報告に明記する点に注意する
6. 報告: 確認観点 × 対象ページ × 結果の表にまとめる。確認した全ルートと console クリーンを明記する。課題は切り分け結果と根拠を明記する。CUD・課金が必要で実施できなかった確認は、ユーザーに代替操作を依頼した内容として明記する

インタラクションの区分

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

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

注意

• 網羅性（対象ページ数・件数）を head / grep -A N などの部分ビューを根拠に断定しない。完全出力（grep -c / wc -l）で数える
• console エラーが無いことと正しく描画されていることは別。重要ページは snapshot で主要要素の実在まで確認する