full-page-screenshot

Overview of full-page-screenshot skill

What full-page-screenshot does

full-page-screenshot is a Browser Automation skill for capturing a complete web page as a single PNG, including content below the fold. It is built around a standalone Node.js script that talks to Chrome through the Chrome DevTools Protocol, so it can handle long pages, lazy-loaded content, single-page apps, and pages where a normal viewport screenshot would miss most of the content.

Best-fit users and jobs

Install this skill if you need an AI agent to reliably produce full-page screenshots during QA, visual review, documentation, design audits, bug reports, competitive research, or authenticated product walkthroughs. It is especially useful when the target page is already open in Chrome, because the skill can list available tabs and capture the selected tab without asking the user to re-create login state.

Key differentiators

The main value of the full-page-screenshot skill is operational reliability: it uses Chrome DevTools Protocol directly, has zero external package dependencies beyond Node.js 22+ and Chrome/Chromium, and supports both existing-tab capture and URL-based capture. The existing-tab workflow is the important differentiator for authenticated dashboards, staging environments, and pages behind SSO.

Adoption constraints to check first

Before installing, confirm that your environment can run Node.js 22+ and that Chrome remote debugging is available. The skill is not a hosted screenshot API and does not bypass authentication, CAPTCHAs, local network restrictions, cookie banners, or pages that intentionally block automation. It works best when the user can open the page normally in Chrome and let the agent capture it from there.

How to Use full-page-screenshot skill

full-page-screenshot install and readiness check

Install the skill from the repository path:

npx skills add alirezarezvani/claude-skills --skill full-page-screenshot

After installation, start with SKILL.md, then inspect scripts/full-page-screenshot.mjs. The script is the execution layer, so it is worth reading before using the skill in a locked-down or CI-like environment.

Run the readiness check:

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --check

If Chrome debugging is unavailable, open chrome://inspect/#remote-debugging and enable remote debugging for the browser instance, or launch Chrome/Chromium with a debugging port according to your local policy.

Existing-tab usage for logged-in pages

For authenticated pages, admin panels, or anything that depends on your current browser session, use the existing-tab workflow. First list open tabs:

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --list

Find the tab by title or URL, then capture it:

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" <targetId> /tmp/screenshot.png --width 1200 --dpr 1

This avoids losing session cookies and is usually more reliable than opening a fresh URL in the background. Use a width that matches the design breakpoint you want to review, such as 390 for mobile-like layout, 768 for tablet, or 1200/1440 for desktop.

URL usage for public pages

For public pages, documentation, marketing pages, or pages that do not require login, use URL mode:

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --url "https://example.com" /tmp/screenshot.png --width 1200 --dpr 1 --wait 15000

Increase --wait when the page relies on delayed rendering, client-side routing, analytics-triggered content, or lazy-loaded sections. Keep --dpr 1 for practical file sizes and review speed; use a higher DPR only when pixel density matters more than output size.

Prompt pattern for better invocation

A weak prompt is: “Take a screenshot of this page.” A stronger full-page-screenshot usage prompt includes URL or tab context, authentication state, viewport width, waiting needs, and output path:

Use the full-page-screenshot skill to capture the already-open Chrome tab for staging.example.com/dashboard. I am logged in. Use desktop width 1440, DPR 1, 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.

This gives the agent enough information to choose between --list, existing-tab capture, and --url mode without guesswork.

full-page-screenshot skill FAQ

Is full-page-screenshot better than an ordinary screenshot prompt?

Yes, when the requirement is a complete page capture rather than the visible viewport. A generic prompt may rely on whatever screenshot capability the environment exposes, often producing only the current screen. The full-page-screenshot skill gives the agent a specific CDP-based workflow, command structure, and fallback path for already-open tabs.

Can beginners use this skill?

Yes, if they can install skills and run Chrome with remote debugging enabled. The commands are straightforward, but the setup is more technical than a browser extension. Beginners should start with --check, then --list, then capture an existing tab before trying URL mode.

When should I not use this skill?

Do not use it when you need scheduled screenshot monitoring, cross-browser rendering comparison, screenshot diffing, OCR, PDF export, or cloud execution at scale. This skill captures PNG screenshots from Chrome/Chromium; it does not replace Playwright test suites, visual regression platforms, or hosted screenshot APIs.

Does it work for Browser Automation workflows?

Yes. full-page-screenshot for Browser Automation is a strong fit when an agent needs a deterministic capture step after navigating, logging in, applying filters, or waiting for a UI state. It is most useful as the final capture tool in a broader browser workflow, not as a complete navigation or testing framework by itself.

How to Improve full-page-screenshot skill

Improve full-page-screenshot inputs

Better inputs produce better screenshots. Specify the page state, not just the page address: logged-in account, selected filters, modal state, viewport width, expected loaded elements, and output filename. If the page is dynamic, name the element or section that must be visible before capture so the agent knows when a longer wait or manual confirmation is needed.

Reduce common capture failures

The most common blockers are Chrome remote debugging not being enabled, choosing URL mode for pages that require login, capturing before lazy content finishes loading, and using the wrong viewport width. Fix these by running --check, preferring existing-tab mode for authenticated pages, increasing --wait for public SPAs, and matching --width to the layout you actually want to inspect.

Iterate after the first PNG

Review the first output for missing bottom content, sticky headers covering sections, cookie banners, unloaded images, or unexpected responsive layout. Then rerun with a different width, longer wait, or an already-prepared tab. If a cookie banner or modal appears, dismiss it in Chrome first and capture the existing tab rather than relying on a fresh background URL.

Read the script before extending

If you want to customize the skill, read scripts/full-page-screenshot.mjs before editing prompts. The script controls tab discovery, viewport width, DPR, waiting behavior, and CDP capture. Useful improvements may include clearer error messages, additional wait strategies, output naming conventions, or optional CSS handling for hiding sticky overlays when your workflow permits it.