shoji9x9 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 等〉を参照するか）はプロジェクトごとに異なる。分離を確認できない限り、書き込み・課金操作は共有環境に影響する前提で承認を求める
- 呼び出し元スキルから環境を渡されたときは、渡された環境だけを使う。設定ファイル（
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 が無効・未設定のときはユーザーに有効化を促し、本スキルを中断する。 中断するときは、環境が整った後に実施する確認内容（対象ページと確認観点の一覧）を導出して報告に残してから中断する（ローカル環境が起動していない等、他の理由で中断する場合も同じ）
- WSL で実行する場合: Chrome 本体と CJK フォント（
fonts-noto-cjk。日本語の文字化け防止） - ツール:
git（確認スコープの導出）、curl（ローカル環境の稼働確認）
プロジェクト設定の解決
環境（名前・URL・認証・既定・禁止操作）・ローカル起動方法はリポジトリごとに異なる。解決手順（設定ファイル → リポジトリ探索 → ユーザー確認）と設定ファイル .config/skills/shoji9x9/skills.yml の扱いは references/project-config.md を参照する。
セットアップモード（browser-test setup。この解決を対話的に先回りして行い、設定ファイルへ記録する）の手順も同ファイルにある。
フロー
- 環境とスコープの確定: 呼び出し元スキルから環境を渡されたときは環境の解決を行わず（設定ファイルを開かない・存在確認もしない）、渡された環境をそのまま使う（「厳守の制約」参照）。
それ以外はプロジェクト設定を解決し、環境（既定は設定で
defaultとされた環境）をユーザーに確認する。確認スコープはいずれの場合もユーザーに確認する。 認証が必要な環境はユーザーがログインを実施する。「ログインが完了したら教えてください」と伝え、完了の合図を待ってから確認を始める - サーバ稼働確認（ローカル選択時）: まず解決した URL 群（
check_urls。省略時はurl）にcurl -s -o /dev/null -w "%{http_code}"で疎通確認する。稼働していればpre_commands/startは実行せず次へ進む。 落ちていれば確認を始めず、解決済みのpre_commands（あれば）と起動コマンドをまとめて提示してユーザーに実行を促す。本スキルはこれらを自動実行しない（build / codegen 等の副作用を承認なく起こさない）。 起動完了の合図を受けたら疎通確認をやり直し、通らなければそこで停止する - 確認スコープの取得と影響ページの導出:
- スコープ:
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 を承認なしにトリガーしない（「厳守の制約」に従う）
- スコープ:
- 各ページの確認: 各対象ルートについて次を行う
navigate_pageで対象 URL を開く。非同期描画はwait_forで完了を待つlist_console_messagesで error / warn がゼロであることを確認する。console メッセージはナビゲーションごとにリセットされるため、ページを開いた直後に確認する- 必要に応じて
take_snapshotで描画内容（主要要素・一覧件数・見出し）を確認する。snapshot は巨大化しうるため、大きい場合はファイル保存オプションを使い必要部分のみ読む。要素識別子（uid）はページ再描画で変わるため、click等の直前に取り直す - 主要コンポーネントは副作用のないインタラクションを中心に動作確認する。副作用を伴う操作は「厳守の制約」に従う
- 課題発見時のクロス環境切り分け: 課題を見つけたら今回の変更起因かを確定する前に切り分ける。変更を含まない別環境（デプロイ済み環境等）で同じ操作を再現する。再現すれば既存・環境起因の可能性が高く、再現しなければ今回の変更起因の可能性が高い。デプロイ済みコードがベースブランチと一致するとは限らない点、認証が必要でクロス確認できない場合はユーザーに依頼する点、切り分け結果（今回の変更起因／既存／環境・データ起因／切り分け未完）を報告に明記する点に注意する
- 報告: 確認観点 × 対象ページ × 結果の表にまとめる。確認した全ルートと console クリーンを明記する。課題は切り分け結果と根拠を明記する。CUD・課金が必要で実施できなかった確認は、ユーザーに代替操作を依頼した内容として明記する
インタラクションの区分
| 区分 | 操作例 |
|---|---|
| 副作用なし（承認不要で実施可） | ページ遷移、検索ボックスへの入力、ドロップダウンの開閉、行の展開、タブ切替、フィルタ選択 |
| 副作用あり（実施前に承認） | 「保存」「実行」「削除」「送信」など書き込み・課金・生成・通知を伴うボタン |
副作用ありの操作でも、環境の forbidden_actions に該当するものは実施せず、ユーザーに実施を依頼する（--ignore-forbidden-actions 指定時を除く。「厳守の制約」参照）。
注意
- 網羅性（対象ページ数・件数）を
head/grep -A Nなどの部分ビューを根拠に断定しない。完全出力（grep -c/wc -l）で数える - console エラーが無いことと正しく描画されていることは別。重要ページは snapshot で主要要素の実在まで確認する