setup-browser-cookies

setup-browser-cookies スキルの概要

setup-browser-cookies でできること

setup-browser-cookies スキルは、実際の Chromium ブラウザから cookie を取り出し、headless のブラウジングセッションに取り込むためのスキルです。ログイン済みの状態が前提になる認証済み QA やブラウザ自動化の作業で、テストを始める前にすでにサインインされた状態が必要な場面を想定しています。

どんな人に向いているか

次のような作業が多いなら、setup-browser-cookies スキルを導入する価値があります。

• ログイン後のページをテストしたい
• 認証済みフローの不具合を再現したい
• 実ブラウザのセッションを自動化に引き継ぎたい
• 毎回手動で認証状態を作り直したくない

このスキルが他と違う理由

単に「先にログインして」と書くだけの汎用プロンプトと違い、setup-browser-cookies は明示的な cookie 取り込みの手順と、対話的な選択ステップを追加します。headless セッションにどの domain を引き継ぐかを細かく制御したいとき、この違いは大きいです。単に認証すればいいのではなく、どの範囲まで状態を持ち込むかを管理できます。

どんなときに適しているか

setup-browser-cookies for Browser Automation は、Chromium ですでにブラウザ状態が存在していて、それを安全に再利用したいときに最適です。いっぽうで、ログイン情報の入力、MFA の処理、まったく新しい認証フローを最初から通す必要がある場合には、あまり向いていません。

setup-browser-cookies スキルの使い方

スキルをインストールする

環境に応じてリポジトリの skill install フローを使い、setup-browser-cookies という名前でスキルが利用可能になっていることを確認してください。skill manager を使う構成なら、package をインストールしたうえで、skill ディレクトリに SKILL.md と SKILL.md.tmpl が含まれているかを確認します。

適切なタスクプロンプトから始める

このスキルは、どの認証済みブラウザ状態が必要なのかをはっきり伝えるほど、うまく機能します。よい入力には次のような情報が含まれます。

• 対象の site や app
• ログイン後に実行したい task
• すべての cookie を使うのか、特定 domain だけにするのか
• Chromium 限定アクセスなどの browser constraint

より強いプロンプトの例は次の通りです。setup-browser-cookies を使って example.com の Chromium cookie を取り込み、そのあと dashboard を開いて billing page が authenticated user として表示されることを確認してください。

まず何を読むべきか

setup-browser-cookies usage の流れに頼る前に、次を確認してください。

• SKILL.md で正確な操作手順を確認する
• SKILL.md.tmpl で、スキルがどのように生成され、どこが安定仕様なのかを見る
• preamble、safe operations、skill routing を扱う section を確認する

これらはファイル全体をざっと眺めるより重要です。いつこのスキルを動かすべきか、そして session に何を期待しているかが分かるからです。

実務で役立つワークフローのコツ

よりよい結果を得るには、agent に次の情報を伝えてください。

• cookie が保存されている browser profile や machine
• multi-domain auth が想定されるかどうか
• cookie picker に domain が多すぎる場合にどうしてほしいか
• 目的が read-only の確認か、data を変更する操作か

タスクがあいまいだと、スキルが誤った domain を取り込んだり、早すぎる段階で止まったりします。site 名だけでなく、どの authenticated page を重視するのかまで明確にしてください。

setup-browser-cookies スキル FAQ

setup-browser-cookies は Chromium 専用ですか？

このスキルは、実際の Chromium ブラウザから cookie を headless session に取り込むことを前提に設計されています。browser state が別の場所にある場合は、すでにその差を埋める workflow があるのでない限り、最適な選択ではないかもしれません。

それでもログイン情報は必要ですか？

有効な browser session がすでに存在しているなら、多くの場合は不要です。setup-browser-cookies スキルは、credentials を入力して app の login process を置き換えるためではなく、認証済み状態を再利用するためのものです。

通常の「ログインして」と書くプロンプトより優れていますか？

session reuse がボトルネックなら、はい、優れています。通常のプロンプトでも login 行動は指示できますが、setup-browser-cookies install では、再現性のある cookie import pattern と、認証済み browser 作業を始めるためのより明確なトリガーが得られます。

どんなときに使うべきではありませんか？

次のような場合は使わないでください。

• 新規 account 作成フローが必要
• password reset の手順が必要
• 手動の MFA enrollment が必要
• 非 Chromium の session transfer が必要

このようなケースでは、より広い browser automation スキルや、task-specific な login prompt のほうが一般に適しています。

setup-browser-cookies スキルをどう改善するか

正しい session target を与える

改善の鍵は、指示を増やすことではなく、session target をより正確にすることです。正確な site、認証後に開く route、そして import 後に agent が止まるべき地点を明記してください。そうすれば、cookie 読み込み後の推測を減らせます。

cookie の対象範囲のあいまいさを減らす

環境に複数の subdomain があるなら、どれが重要かを明示してください。たとえば、app.example.com と api.example.com の cookie は取り込むが、marketing domain は無視する、といった指定です。そうすることで、無関係な domain を取り込んで session が散らかったり、判別しづらくなったりするのを避けやすくなります。

最初に起こりやすい失敗に備える

最も多い失敗は、不完全な auth state です。ページは開くのに、まだ login wall が出る、session が期限切れになっている、アクセス権が一部しかない、といった状態です。そうなったら、import 後に何が見えていたか、どの domain で失敗したか、browser profile にすでに live session があったかを prompt に追加してください。

outcome ベースの feedback で反復する

最初の実行後は、agent に何を確認してほしいかを具体化してください。

• 「account menu に logged-in user が表示されることを確認して」
• 「admin page を開いて session が維持されているか確認して」
• 「import に失敗したら、別の domain set で再試行する前に確認を求めて」

この種の feedback は、setup-browser-cookies guide を、最初の目的を言い直すだけの場合よりずっと効果的にします。