full-page-screenshot
von alirezarezvanifull-page-screenshot erfasst vollständige Chrome/Chromium-Seiten als PNGs über CDP, einschließlich langer Seiten, SPAs, Lazy-Loaded Content und angemeldeter Tabs. Nutze den Skill mit Node.js 22+, Chrome Remote Debugging, --check, --list, Existing-Tab-Capture oder --url mode.
Dieser Skill erreicht 82/100 Punkte und ist damit ein solider Kandidat für Verzeichnisnutzer, die zuverlässige Full-Page-Browser-Screenshots benötigen. Er bietet klare Trigger, praxisnahe Befehle und ein ausführbares Skript. Nutzer sollten jedoch die Anforderungen an Chrome Remote Debugging und Node.js 22+ einplanen.
- Sehr gut auslösbar: Das Frontmatter nennt ausdrücklich vollständige, lange und komplette Screenshots von Webseiten.
- Der operative Ablauf ist konkret beschrieben, mit Befehlen für Umgebungschecks, das Auflisten vorhandener Tabs, das Erfassen authentifizierter/geöffneter Tabs und das Erfassen einer URL in einem Hintergrund-Tab.
- Enthält ein eigenständiges Node.js-Skript auf Basis des Chrome DevTools Protocol und gibt Agents damit wiederverwendbare Möglichkeiten über einen generischen Prompt hinaus.
- Erfordert Node.js 22+ sowie Chrome/Chromium mit aktiviertem Remote Debugging; es ist daher keine Ein-Befehl-Installation mit sofortiger Nutzung.
- Im Skill-Pfad gibt es keinen Installationsbefehl und keine README. Nutzer sind deshalb unter Umständen auf Directory-Tools oder die Repository-Struktur angewiesen, um SKILL_DIR korrekt zu setzen.
Überblick über den full-page-screenshot skill
Was full-page-screenshot macht
full-page-screenshot ist ein Browser Automation skill, der eine vollständige Webseite als einzelne PNG-Datei erfasst – einschließlich Inhalte unterhalb des sichtbaren Bereichs. Der full-page-screenshot skill basiert auf einem eigenständigen Node.js-Skript, das über das Chrome DevTools Protocol mit Chrome kommuniziert. Dadurch eignet er sich für lange Seiten, Lazy-Loaded Content, Single-Page-Apps und Seiten, bei denen ein normaler Viewport-Screenshot den Großteil des Inhalts verfehlen würde.
Für wen und welche Aufgaben der Skill am besten geeignet ist
Installieren Sie diesen Skill, wenn ein AI Agent zuverlässig vollständige Seiten-Screenshots für QA, visuelle Reviews, Dokumentation, Design-Audits, Bug Reports, Wettbewerbsrecherche oder authentifizierte Produkt-Walkthroughs erstellen soll. Besonders nützlich ist er, wenn die Zielseite bereits in Chrome geöffnet ist: Der Skill kann verfügbare Tabs auflisten und den ausgewählten Tab erfassen, ohne dass der Nutzer den Login-Zustand erneut herstellen muss.
Zentrale Unterscheidungsmerkmale
Der wichtigste Mehrwert des full-page-screenshot skill liegt in seiner betrieblichen Zuverlässigkeit: Er nutzt das Chrome DevTools Protocol direkt, kommt ohne externe Paketabhängigkeiten jenseits von Node.js 22+ und Chrome/Chromium aus und unterstützt sowohl das Erfassen vorhandener Tabs als auch URL-basierte Aufnahmen. Der Workflow mit vorhandenen Tabs ist der entscheidende Vorteil bei authentifizierten Dashboards, Staging-Umgebungen und Seiten hinter SSO.
Voraussetzungen, die Sie vor der Einführung prüfen sollten
Prüfen Sie vor der Installation, ob Ihre Umgebung Node.js 22+ ausführen kann und ob Chrome Remote Debugging verfügbar ist. Der Skill ist keine gehostete Screenshot-API und umgeht weder Authentifizierung noch CAPTCHAs, lokale Netzwerkbeschränkungen, Cookie-Banner oder Seiten, die Automatisierung absichtlich blockieren. Am besten funktioniert er, wenn der Nutzer die Seite normal in Chrome öffnen und der Agent sie von dort aus erfassen kann.
So verwenden Sie den full-page-screenshot skill
full-page-screenshot installieren und Einsatzbereitschaft prüfen
Installieren Sie den Skill aus dem Repository-Pfad:
npx skills add alirezarezvani/claude-skills --skill full-page-screenshot
Beginnen Sie nach der Installation mit SKILL.md und prüfen Sie anschließend scripts/full-page-screenshot.mjs. Das Skript ist die Ausführungsschicht; es lohnt sich daher, es vor dem Einsatz in einer stark eingeschränkten Umgebung oder in einem CI-ähnlichen Setup zu lesen.
Führen Sie den Readiness Check aus:
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --check
Wenn Chrome Debugging nicht verfügbar ist, öffnen Sie chrome://inspect/#remote-debugging und aktivieren Sie Remote Debugging für die Browser-Instanz, oder starten Sie Chrome/Chromium gemäß Ihrer lokalen Richtlinie mit einem Debugging-Port.
Vorhandene Tabs für eingeloggte Seiten nutzen
Für authentifizierte Seiten, Admin-Bereiche oder alles, was von Ihrer aktuellen Browser-Session abhängt, sollten Sie den Existing-Tab-Workflow verwenden. Listen Sie zuerst die geöffneten Tabs auf:
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --list
Suchen Sie den Tab anhand von Titel oder URL und erfassen Sie ihn dann:
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" <targetId> /tmp/screenshot.png --width 1200 --dpr 1
So gehen keine Session-Cookies verloren; in der Regel ist das zuverlässiger, als eine frische URL im Hintergrund zu öffnen. Verwenden Sie eine Breite, die dem Design-Breakpoint entspricht, den Sie prüfen möchten, zum Beispiel 390 für ein mobilähnliches Layout, 768 für Tablet oder 1200/1440 für Desktop.
URL-Modus für öffentliche Seiten
Für öffentliche Seiten, Dokumentation, Marketing-Seiten oder Seiten ohne Login verwenden Sie den URL-Modus:
node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --url "https://example.com" /tmp/screenshot.png --width 1200 --dpr 1 --wait 15000
Erhöhen Sie --wait, wenn die Seite verzögertes Rendering, clientseitiges Routing, durch Analytics ausgelöste Inhalte oder Lazy-Loaded Sections verwendet. Behalten Sie --dpr 1 bei, wenn Dateigröße und Review-Geschwindigkeit wichtiger sind; nutzen Sie eine höhere DPR nur, wenn Pixeldichte wichtiger ist als die Ausgabedateigröße.
Prompt-Muster für bessere Aufrufe
Ein schwacher Prompt wäre: „Mach einen Screenshot dieser Seite.“ Ein stärkerer Prompt für die Nutzung von full-page-screenshot enthält URL- oder Tab-Kontext, Authentifizierungsstatus, Viewport-Breite, Warteanforderungen und Ausgabepfad:
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.
Damit hat der Agent genug Informationen, um ohne Raten zwischen --list, dem Erfassen eines vorhandenen Tabs und dem --url-Modus zu wählen.
FAQ zum full-page-screenshot skill
Ist full-page-screenshot besser als ein gewöhnlicher Screenshot-Prompt?
Ja, wenn eine vollständige Seitenerfassung benötigt wird und nicht nur der sichtbare Viewport. Ein generischer Prompt nutzt möglicherweise einfach die Screenshot-Funktion, die die Umgebung gerade bereitstellt, und liefert häufig nur den aktuellen Bildschirmausschnitt. Der full-page-screenshot skill gibt dem Agenten einen konkreten CDP-basierten Workflow, eine klare Befehlsstruktur und einen Fallback-Pfad für bereits geöffnete Tabs.
Können Einsteiger diesen Skill verwenden?
Ja, sofern sie Skills installieren und Chrome mit aktiviertem Remote Debugging ausführen können. Die Befehle sind überschaubar, aber die Einrichtung ist technischer als bei einer Browser-Erweiterung. Einsteiger sollten mit --check beginnen, anschließend --list ausführen und dann zunächst einen vorhandenen Tab erfassen, bevor sie den URL-Modus ausprobieren.
Wann sollte ich diesen Skill nicht verwenden?
Verwenden Sie ihn nicht, wenn Sie geplantes Screenshot-Monitoring, Cross-Browser-Rendering-Vergleiche, Screenshot-Diffing, OCR, PDF-Export oder Cloud-Ausführung im großen Maßstab benötigen. Dieser Skill erstellt PNG-Screenshots aus Chrome/Chromium; er ersetzt keine Playwright-Test-Suites, Visual-Regression-Plattformen oder gehosteten Screenshot-APIs.
Funktioniert er für Browser Automation Workflows?
Ja. full-page-screenshot for Browser Automation passt sehr gut, wenn ein Agent nach Navigation, Login, Filterauswahl oder dem Warten auf einen bestimmten UI-Zustand einen deterministischen Erfassungsschritt braucht. Am nützlichsten ist er als abschließendes Capture-Werkzeug innerhalb eines größeren Browser-Workflows, nicht als vollständiges Navigations- oder Testing-Framework für sich allein.
So verbessern Sie den full-page-screenshot skill
full-page-screenshot-Eingaben verbessern
Bessere Eingaben führen zu besseren Screenshots. Beschreiben Sie den Seitenzustand, nicht nur die Seitenadresse: eingeloggter Account, ausgewählte Filter, Modal-Zustand, Viewport-Breite, erwartete geladene Elemente und Ausgabedateiname. Wenn die Seite dynamisch ist, nennen Sie das Element oder den Abschnitt, der vor der Aufnahme sichtbar sein muss, damit der Agent weiß, wann längeres Warten oder eine manuelle Bestätigung nötig ist.
Häufige Erfassungsfehler reduzieren
Die häufigsten Blocker sind deaktiviertes Chrome Remote Debugging, die Wahl des URL-Modus für Seiten mit Login-Pflicht, eine Aufnahme vor Abschluss des Lazy Loading und eine falsche Viewport-Breite. Beheben Sie das, indem Sie --check ausführen, bei authentifizierten Seiten den Existing-Tab-Modus bevorzugen, bei öffentlichen SPAs --wait erhöhen und --width an das Layout anpassen, das Sie tatsächlich prüfen möchten.
Nach der ersten PNG iterieren
Prüfen Sie die erste Ausgabe auf fehlende Inhalte am Seitenende, Sticky Header, die Abschnitte verdecken, Cookie-Banner, nicht geladene Bilder oder ein unerwartetes responsives Layout. Führen Sie den Capture anschließend erneut mit anderer Breite, längerer Wartezeit oder einem bereits vorbereiteten Tab aus. Wenn ein Cookie-Banner oder Modal erscheint, schließen Sie es zuerst in Chrome und erfassen Sie den vorhandenen Tab, statt sich auf eine frische Hintergrund-URL zu verlassen.
Skript vor Erweiterungen lesen
Wenn Sie den Skill anpassen möchten, lesen Sie scripts/full-page-screenshot.mjs, bevor Sie Prompts bearbeiten. Das Skript steuert Tab-Erkennung, Viewport-Breite, DPR, Warteverhalten und CDP-Capture. Sinnvolle Verbesserungen können klarere Fehlermeldungen, zusätzliche Wait-Strategien, Konventionen für Ausgabedateinamen oder optionales CSS-Handling zum Ausblenden von Sticky Overlays sein, sofern Ihr Workflow das erlaubt.