browse

browse skill の概要

browse は何のための skill か

browse skill は、QA、dogfooding、ブラウザ自動化のための高速なヘッドレスブラウザツールです。ページを開く、操作する、状態を確認する、操作前後を比較する、スクリーンショットや要素状態チェックのような証拠を取る、といった用途を想定しています。要するに「ブラウザでこのフローを試して、何が起きたか教えてほしい」という仕事には、browse が最適です。

どんな人がインストールすべきか

Web ページ、デモ、フォーム、レスポンシブレイアウト、アップロード、ダイアログ、デプロイ確認を定期的に検証するなら、browse をインストールする価値があります。特に、一般的なプロンプト任せではなく、スクリーンショットや状態アサーションで UI の振る舞いを証明する必要があるエージェントに向いています。逆に、純粋なバックエンド作業や単純なページ閲覧だけなら、優先度は高くありません。

browse が他と違う点

browse skill は、単なるテキストベースのページ閲覧ではなく、実際のブラウザ実行を前提に作られています。repo には command routing、browser management、CDP bridging、network capture、cookie handling、注釈付きの visual checks への対応を示す要素があります。つまり browse は、「このサイトを要約する」ような軽い補助ではなく、証拠を伴う実用的なブラウザ自動化を狙った skill です。

browse skill の使い方

browse を正しくインストールする

skill docs に示されている install path、または skill manager の add command を使ってインストールし、その後でローカルの skill directory から browse が見つかることを確認してください。repo には bin/find-browse のような helper shim が含まれており、browse は workspace を意識した install 先から見つけて実行する設計だと読み取れます。binary が見つからない場合は、プロンプトを書き換えるより先に、skill の setup/build 経路を実行するのが基本です。

抽象的な目的ではなく、具体的なブラウザ作業を渡す

browse をうまく使うには、URL、操作内容、期待結果、返してほしい証拠を明確にすることが出発点です。良い入力の例は、「ログインページを開き、有効な認証情報で送信し、/dashboard へリダイレクトされることを確認して、スクリーンショットと console / network エラーを返してほしい」です。一方で「サイトをテストして」は、ルーティングの曖昧さが大きすぎます。

先に読むべきファイル

インストール判断や使い方を見極めるなら、まず SKILL.md を読み、その後で既知の workflow 制約を確認するために PLAN-snapshot-dropdown-interactive.md、skill の生成方法を見るために SKILL.md.tmpl、パスと repo 解決の挙動を理解するために bin/find-browse と bin/remote-slug を確認してください。ブラウザ自動化としてどこまで実行できるかを評価するなら、src/browser-manager.ts、src/cdp-bridge.ts、src/browser-skill-commands.ts もざっと見ておくと判断しやすくなります。

workflow の中で browse を使う

安定した browse workflow は、まず欲しいページ状態を定義し、次にブラウザ操作を実行し、出力を検証してから、次の制約へ進む、という流れです。たとえば、レスポンシブの幅、フォーム入力、期待する DOM 変化を事前に指定しておけば、browse は一度の実行でまとめて確認できます。これによりやり取りの往復が減り、ただの一般的なプロンプトよりも初回実行の情報量が増えます。

browse skill FAQ

browse はスクリーンショット専用ですか？

いいえ。スクリーンショットは出力の一部にすぎません。browse skill は、ナビゲーション、操作、状態確認、レスポンシブ確認、フォームテスト、アップロード、バグ証拠の取得にも使う前提です。実際に欲しいのが「このブラウザ動作を証明すること」なら、browse はスクリーンショット専用ツールよりもずっと用途が広いです。

browse は通常のプロンプトと何が違いますか？

通常のプロンプトは、エージェントにブラウザ作業を推論させます。browse skill は、command routing や browser-state checks を含む、ブラウザ向けの実行経路をエージェントに与えます。その結果、推測が減り、再現性が上がり、フローが失敗したときの証拠も明確になりやすくなります。

browse は初心者にも使いやすいですか？

はい、ブラウザ作業をはっきり説明できるなら使いやすいです。初心者は、URL、1つの操作、1つの期待結果、1つの証拠要求をセットで渡すと成功しやすくなります。すでにテストケースの書き方を知っているなら、browse は最初から十分実用的に使えることが多いです。

どんなときに browse を使わないほうがいいですか？

静的な内容抽出、repo の調査、単純なコーディング回答だけが必要なときは、browse は向きません。ブラウザ対象を指定できない場合や、実際にレンダリングされたページが不要な作業でも、適合度は低いです。そういう場面では、通常のエージェントプロンプトのほうがシンプルです。

browse skill を改善するには

ブラウザ入力をもっと具体的にする

browse の結果が最も良くなるのは、ページ名、ユーザー操作、成功条件、返してほしい成果物を明示した入力です。たとえば、「pricing ページで年額課金に切り替え、合計金額が更新されることを確認し、最終状態のスクリーンショットを保存する」といった指定です。これは「pricing を確認して」よりもずっと良く、成功の意味が曖昧になりません。

よくある失敗パターンに注意する

browse で最も多い失敗は、仕様不足です。URL がない、状態がない、期待結果がない、といったケースです。次に多いのは、ページのどの部分が重要かを示さずに、見た目の証拠だけを求めることです。フォーム、メニュー、ダイアログ、動的コンテンツが含まれるなら、その旨を明示してください。そうした詳細は browse の使い方に大きく影響します。

1回目の実行後に詰める

最初の結果がかなり近いが完全ではないなら、次のプロンプトではズレをそのまま具体化してください。viewport が違う、要素を見落とした、state が古い、network evidence が足りない、などです。browse は、各パスで不確実性を狭めるほど価値が高まります。同じ依頼を言い換えるより、出力を見て制約を追加するほうが効果的です。

Browser Automation 向けに browse を調整する

browser automation では、テストアカウントの種類、デバイスサイズ、ロケール、cookie やログイン状態が関係するかどうかを具体的に含めてください。バグ検証なら、再現手順と expected / actual の差分も入れます。こうすると browse は一般的な QA メモ係ではなく、ブラウザ自動化アシスタントとして機能しやすくなり、初回からより良い証拠が得られます。