full-page-screenshot
作成者 alirezarezvanifull-page-screenshot は、CDP 経由で Chrome/Chromium のページ全体を PNG としてキャプチャするスキルです。長いページ、SPA、遅延読み込みコンテンツ、ログイン済みタブにも対応します。Node.js 22+、Chrome remote debugging、--check、--list、existing-tab capture、または --url mode と組み合わせて使用します。
このスキルの評価は82/100で、信頼性の高いフルページのブラウザスクリーンショットが必要なディレクトリ利用者にとって有力な掲載候補です。トリガー条件、実用的なコマンド、実行可能なスクリプトがそろっていますが、Chrome のリモートデバッグ設定と Node.js 22+ が必要な点には注意が必要です。
- トリガー条件が明確です。frontmatter で、Webページの full-page、long、complete page screenshots を明示的に対象にしています。
- 運用手順が具体的で、環境チェック、既存タブの一覧表示、認証済み/開いているタブのキャプチャ、バックグラウンドタブでの URL キャプチャに使うコマンドが用意されています。
- Chrome DevTools Protocol を使う単体の Node.js スクリプトを含んでおり、汎用プロンプト以上にエージェントから再利用しやすい構成です。
- Node.js 22+ と、リモートデバッグを有効にした Chrome/Chromium が必要なため、1コマンドで導入してすぐ使えるタイプではありません。
- スキルのパス内にインストールコマンドや README がないため、SKILL_DIR を正しく配置するにはディレクトリ側のツールやリポジトリ構成に頼る場面があります。
full-page-screenshot skill の概要
full-page-screenshot でできること
full-page-screenshot は、ファーストビューの下にあるコンテンツまで含めて、Web ページ全体を 1 枚の PNG としてキャプチャする Browser Automation skill です。Chrome DevTools Protocol 経由で Chrome と通信するスタンドアロンの Node.js スクリプトを中心に構成されているため、長いページ、遅延読み込みコンテンツ、シングルページアプリ、通常のビューポートスクリーンショットでは大部分が写らないページにも対応できます。
向いているユーザーと用途
QA、ビジュアルレビュー、ドキュメント作成、デザイン監査、バグ報告、競合調査、認証が必要なプロダクトの walkthrough などで、AI エージェントにフルページのスクリーンショットを安定して作成させたい場合は、この skill の導入が適しています。特に対象ページがすでに Chrome で開かれている場合に便利です。利用可能なタブを一覧表示し、選択したタブをキャプチャできるため、ユーザーにログイン状態を作り直してもらう必要がありません。
主な差別化ポイント
full-page-screenshot skill の大きな価値は、運用時の安定性にあります。Chrome DevTools Protocol を直接利用し、Node.js 22+ と Chrome/Chromium 以外の外部パッケージ依存がなく、既存タブのキャプチャと URL 指定でのキャプチャの両方をサポートしています。認証済みダッシュボード、ステージング環境、SSO の背後にあるページでは、既存タブを使えるワークフローが重要な差別化要素になります。
導入前に確認すべき制約
インストール前に、環境で Node.js 22+ を実行できること、Chrome remote debugging を利用できることを確認してください。この skill はホスト型のスクリーンショット API ではなく、認証、CAPTCHA、ローカルネットワーク制限、Cookie バナー、意図的に自動化をブロックしているページを回避するものではありません。ユーザーが通常どおり Chrome でページを開き、そこからエージェントにキャプチャさせられる状況で最も力を発揮します。
full-page-screenshot skill の使い方
full-page-screenshot のインストールと準備確認
リポジトリパスから skill をインストールします。
npx skills add alirezarezvani/claude-skills --skill full-page-screenshot
インストール後はまず SKILL.md を読み、そのうえで scripts/full-page-screenshot.mjs を確認してください。このスクリプトが実行レイヤーなので、制限の厳しい環境や CI に近い環境で使う前に目を通しておく価値があります。
準備確認を実行します。
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --check
Chrome debugging を利用できない場合は、chrome://inspect/#remote-debugging を開いて対象のブラウザインスタンスで remote debugging を有効にするか、ローカルのポリシーに従って debugging port 付きで Chrome/Chromium を起動してください。
ログイン済みページで既存タブを使う
認証が必要なページ、管理画面、現在のブラウザセッションに依存するものには、既存タブのワークフローを使います。まず開いているタブを一覧表示します。
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --list
タイトルまたは URL でタブを見つけ、次のようにキャプチャします。
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" <targetId> /tmp/screenshot.png --width 1200 --dpr 1
この方法ならセッション Cookie を失わずに済み、バックグラウンドで新しい URL を開くより通常は安定します。レビューしたいデザインのブレークポイントに合わせて幅を指定してください。たとえばモバイル風のレイアウトなら 390、タブレットなら 768、デスクトップなら 1200/1440 が目安です。
公開ページで URL を指定する
公開ページ、ドキュメント、マーケティングページ、ログイン不要のページでは URL mode を使います。
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --url "https://example.com" /tmp/screenshot.png --width 1200 --dpr 1 --wait 15000
ページが遅延レンダリング、クライアントサイドルーティング、分析ツール起点のコンテンツ表示、遅延読み込みセクションに依存している場合は、--wait を長めにします。ファイルサイズとレビュー速度を現実的に保つには --dpr 1 が基本です。出力サイズよりピクセル密度を優先する場合にだけ、より高い DPR を使ってください。
呼び出し精度を上げるプロンプト例
弱いプロンプトは「このページのスクリーンショットを撮って」です。より良い full-page-screenshot のプロンプトには、URL またはタブの文脈、認証状態、ビューポート幅、待機要件、出力パスを含めます。
Use the full-page-screenshot skill to capture the already-open Chrome tab for
staging.example.com/dashboard. I am logged in. Use desktop width1440, DPR1, wait long enough for lazy charts to render, and save the PNG to/tmp/dashboard-full-page.png. If multiple matching tabs exist, list them first and ask me which target ID to use.
これにより、エージェントは推測に頼らず、--list、既存タブのキャプチャ、--url mode のどれを使うべきか判断できます。
full-page-screenshot skill FAQ
full-page-screenshot は通常のスクリーンショット依頼より優れていますか?
ページ全体のキャプチャが必要で、表示中のビューポートだけでは不十分な場合は、はい。一般的なプロンプトでは、環境が提供するスクリーンショット機能に依存することが多く、現在の画面だけが出力される場合があります。full-page-screenshot skill は、CDP ベースの具体的なワークフロー、コマンド構造、すでに開いているタブに対するフォールバック手段をエージェントに与えます。
初心者でもこの skill を使えますか?
はい。skill をインストールでき、Chrome の remote debugging を有効にして実行できるなら利用できます。コマンド自体はわかりやすいものの、ブラウザ拡張機能よりセットアップは技術的です。初心者はまず --check、次に --list、その後に既存タブのキャプチャを試し、URL mode はそのあとに使うのがおすすめです。
この skill を使わないほうがよい場面は?
定期的なスクリーンショット監視、クロスブラウザのレンダリング比較、スクリーンショット差分検出、OCR、PDF エクスポート、大規模なクラウド実行が必要な場合には向いていません。この skill は Chrome/Chromium から PNG スクリーンショットを取得するものです。Playwright のテストスイート、ビジュアルリグレッションプラットフォーム、ホスト型スクリーンショット API の代替にはなりません。
Browser Automation ワークフローで使えますか?
はい。full-page-screenshot for Browser Automation は、エージェントがナビゲーション、ログイン、フィルター適用、UI 状態の待機を行ったあとに、決定的なキャプチャ手順を必要とする場合に適しています。単体で完全なナビゲーションやテストフレームワークとして使うというより、より広いブラウザワークフローの最後に使うキャプチャツールとして特に有用です。
full-page-screenshot skill を改善する方法
full-page-screenshot の入力情報を改善する
入力が具体的であるほど、スクリーンショットの品質は上がります。ページのアドレスだけでなく、ページの状態を指定してください。ログイン済みアカウント、選択済みフィルター、モーダルの状態、ビューポート幅、読み込み完了を期待する要素、出力ファイル名などです。ページが動的な場合は、キャプチャ前に表示されているべき要素やセクションを明示すると、エージェントが長めの待機や手動確認の必要性を判断しやすくなります。
よくあるキャプチャ失敗を減らす
よくある原因は、Chrome remote debugging が有効になっていないこと、ログインが必要なページで URL mode を選ぶこと、遅延コンテンツの読み込み完了前にキャプチャすること、意図したレイアウトと異なるビューポート幅を使うことです。対策として、--check を実行し、認証が必要なページでは既存タブ mode を優先し、公開 SPA では --wait を長めにし、確認したいレイアウトに合わせて --width を指定してください。
最初の PNG を見て調整する
最初の出力を確認し、ページ下部のコンテンツ抜け、sticky header がセクションを覆っていないか、Cookie バナー、未読み込み画像、想定外のレスポンシブレイアウトがないかを見ます。そのうえで、幅を変える、待機時間を延ばす、あらかじめ準備したタブを使うなどして再実行してください。Cookie バナーやモーダルが表示される場合は、Chrome 上で先に閉じてから、新しいバックグラウンド URL に頼らず既存タブをキャプチャします。
拡張する前にスクリプトを読む
skill をカスタマイズしたい場合は、プロンプトを編集する前に scripts/full-page-screenshot.mjs を読んでください。このスクリプトが、タブ検出、ビューポート幅、DPR、待機動作、CDP capture を制御しています。有用な改善としては、エラーメッセージの明確化、追加の待機戦略、出力ファイル名の規約、ワークフロー上許可される場合に sticky overlay を隠すための任意の CSS 処理などが考えられます。
