verify-in-browser

ブラウザーで検証する

コードレビューでは差分を読みますが、これはビルドされたものを操作し、実際の動作を報告します。ケースの導出、準備、報告はあなたが行い、サブエージェントが操作します。

1. ケースを導出する

該当する最初の入力を使います。仕様書やチケット、PR、デフォルトブランチとの差分、ユーザーから渡されたものなどです。何もなければ、テスト対象を確認してから進めます。そこから、変更が影響するペルソナと、到達する画面を特定します。不明な場合は、すべてのペルソナを対象にします。各ケースには、ペルソナ、入口、手順、入力から推測した期待結果を含めます。報告には推測内容を明記し、誤りがあれば読んで気づけるようにします。

すべてのケースに4項目が含まれていれば完了です。

2. プロジェクトファイルを読み込む

docs/verify-in-browser.md には、リポジトリだけでは分からない情報を4つのセクションにまとめます。Serve — 起動コマンドとベース URL、Personas — 各ロールとサインイン方法。認証情報は、シードスクリプトに値がすでにコミットされている場合を除き、環境変数名で記載します。Data — シードまたはリセットのコマンドと、各操作担当者の記録を互いに分ける方法。Gotchas — 設定からは分からない注意点です。ファイルがない場合は、リポジトリ全体から起動スクリプト、シードスクリプト、テスト用認証情報を探し、それぞれを実行して確認します。見つからなかった情報だけを1回にまとめてユーザーに尋ね、ファイルを作成し、CLAUDE.md または AGENTS.md があれば、そこからファイルへの参照を追加します。後の実行で事実が異なると判明した場合も、同じ方法でファイルを修正し、その旨を報告します。

アプリが起動してシードデータが投入され、このセッションでケースに必要なすべてのペルソナがサインインできれば完了です。

3. 操作担当者を割り当てる

ペルソナごとに新しいサブエージェントを1つ用意し、並列で割り当てます。Claude Code では model: "sonnet" を指定し、ベース URL、ログイン情報、ファイルの Data セクションと Gotchas セクション、および期待結果を含むケースを渡します。割り当てプロンプトには操作担当者のルールのみを含め、報告に関する指示は含めません。自分のペルソナ名を接頭辞に付けたレコードだけを作成し、完了したら削除すること。操作を妨げるもの（古いフラグや壊れたシードなど）は修正し、テスト対象の動作はそのままにすること。各ケースについて、手順を添えて、pass、observed X, expected Y のいずれか1つだけで返すか、ブロッカーを添えて unreached と返すこと。操作中に不具合らしきものに気づいた場合は、それも報告すること。

すべてのケースについて、判定が1つずつ返ってくれば完了です。

4. 報告する

すべて成功した場合は、N cases across M personas, all pass. の1行だけを返します。それ以外の場合は、失敗したケースについて手順とともに実際の結果と期待結果を示し、続けて操作中に不具合らしきものに気づいた点、最後にこの実行で行った環境の修正をすべて記載します。ユーザーの許可があるまで、変更自体は修正しません。

すべての判定と修正が、それぞれ1回ずつ記載されていれば完了です。