# Browser Test

> フロントエンド／バックエンドの変更が画面表示・コンソール・API 応答・主要コンポーネントの挙動に悪影響を与えていないかを、実ブラウザ（chrome-devtools MCP）で回帰確認するスキル。実施できる操作は環境ごとの設定（`forbidden_actions`）に従い、未定義の環境は読み取り専用として扱う。副作用を伴う操作は実施前にユーザーの承認を得る。環境とスコープからの影響ページ導出・console クリーンの確認・課題のクロス環境切り分けまで進める。バックエンドの変更もそれを呼ぶ画面を通して確認する。`browser-test setup` は対話的にプロジェクト設定を記録する。「ブラウザで確認」「画面で確認して」「browser-test」「動作確認して」「回帰がないか見て」や、`--env` / `--scope` / `--ignore-forbidden-actions` / `setup` を伴う依頼で発動する。

- Skill: `shoji9x9/browser-test` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add shoji9x9/browser-test`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shoji9x9/browser-test/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: shoji9x9 (https://skillmd.com/u/shoji9x9)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shoji9x9/browser-test

---


# Browser Test

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

## 使い方

```text
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`](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`](references/project-config.md) を参照する。
セットアップモード（`browser-test setup`。この解決を対話的に先回りして行い、設定ファイルへ記録する）の手順も同ファイルにある。

## フロー

1. **環境とスコープの確定**: 呼び出し元スキルから環境を渡されたときは環境の解決を行わず（設定ファイルを開かない・存在確認もしない）、渡された環境をそのまま使う（「厳守の制約」参照）。
   それ以外はプロジェクト設定を解決し、環境（既定は設定で `default` とされた環境）をユーザーに確認する。確認スコープはいずれの場合もユーザーに確認する。
   認証が必要な環境はユーザーがログインを実施する。「ログインが完了したら教えてください」と伝え、完了の合図を待ってから確認を始める
2. **サーバ稼働確認（ローカル選択時）**: まず解決した URL 群（`check_urls`。省略時は `url`）に `curl -s -o /dev/null -w "%{http_code}"` で疎通確認する。稼働していれば `pre_commands` / `start` は実行せず次へ進む。
   落ちていれば確認を始めず、解決済みの `pre_commands`（あれば）と起動コマンドを**まとめて提示してユーザーに実行を促す**。本スキルはこれらを自動実行しない（build / codegen 等の副作用を承認なく起こさない）。
   起動完了の合図を受けたら疎通確認をやり直し、通らなければそこで停止する
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 で主要要素の実在まで確認する