full-page-screenshot

Présentation de la skill full-page-screenshot

Ce que fait full-page-screenshot

full-page-screenshot est une skill de Browser Automation qui capture une page web complète dans un seul PNG, y compris le contenu situé sous la ligne de flottaison. Elle repose sur un script Node.js autonome qui communique avec Chrome via le Chrome DevTools Protocol. Elle peut donc gérer les pages longues, le contenu chargé paresseusement, les applications monopages et les pages dont une capture d’écran limitée à la fenêtre visible manquerait l’essentiel.

Utilisateurs et cas d’usage les plus adaptés

Installez cette skill si vous avez besoin qu’un agent IA produise de manière fiable des captures pleine page pour la QA, la revue visuelle, la documentation, les audits design, les rapports de bug, la veille concurrentielle ou les parcours produit authentifiés. Elle est particulièrement utile lorsque la page cible est déjà ouverte dans Chrome, car la skill peut lister les onglets disponibles et capturer l’onglet sélectionné sans demander à l’utilisateur de recréer son état de connexion.

Points différenciants

La valeur principale de la skill full-page-screenshot tient à sa fiabilité opérationnelle : elle utilise directement le Chrome DevTools Protocol, n’a aucune dépendance externe au-delà de Node.js 22+ et Chrome/Chromium, et prend en charge à la fois la capture d’un onglet existant et la capture à partir d’une URL. Le flux de capture d’un onglet existant est le différenciateur important pour les tableaux de bord authentifiés, les environnements de staging et les pages derrière un SSO.

Contraintes d’adoption à vérifier d’abord

Avant l’installation, vérifiez que votre environnement peut exécuter Node.js 22+ et que le débogage distant de Chrome est disponible. La skill n’est pas une API de capture d’écran hébergée et ne contourne ni l’authentification, ni les CAPTCHAs, ni les restrictions de réseau local, ni les bandeaux de cookies, ni les pages qui bloquent volontairement l’automatisation. Elle fonctionne au mieux lorsque l’utilisateur peut ouvrir normalement la page dans Chrome et laisser l’agent la capturer à partir de là.

Comment utiliser la skill full-page-screenshot

Installation de full-page-screenshot et vérification de disponibilité

Installez la skill depuis le chemin du repository :

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

Après l’installation, commencez par SKILL.md, puis examinez scripts/full-page-screenshot.mjs. Le script constitue la couche d’exécution ; il vaut donc la peine d’être lu avant d’utiliser la skill dans un environnement verrouillé ou proche d’un contexte CI.

Lancez la vérification de disponibilité :

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

Si le débogage Chrome n’est pas disponible, ouvrez chrome://inspect/#remote-debugging et activez le débogage distant pour l’instance du navigateur, ou lancez Chrome/Chromium avec un port de débogage conformément à votre politique locale.

Utilisation d’un onglet existant pour les pages connectées

Pour les pages authentifiées, les interfaces d’administration ou tout ce qui dépend de votre session de navigation actuelle, utilisez le flux avec onglet existant. Commencez par lister les onglets ouverts :

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

Repérez l’onglet par son titre ou son URL, puis capturez-le :

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

Cela évite de perdre les cookies de session et s’avère généralement plus fiable que l’ouverture d’une nouvelle URL en arrière-plan. Utilisez une largeur correspondant au point de rupture design que vous voulez examiner, par exemple 390 pour une mise en page proche du mobile, 768 pour tablette, ou 1200/1440 pour desktop.

Utilisation par URL pour les pages publiques

Pour les pages publiques, la documentation, les pages marketing ou les pages qui ne nécessitent pas de connexion, utilisez le mode URL :

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

Augmentez --wait lorsque la page dépend d’un rendu différé, d’un routage côté client, de contenu déclenché par l’analytics ou de sections chargées paresseusement. Conservez --dpr 1 pour garder des fichiers de taille raisonnable et accélérer la revue ; n’utilisez un DPR plus élevé que lorsque la densité de pixels compte davantage que la taille du fichier généré.

Modèle de prompt pour une meilleure exécution

Un prompt faible serait : « Fais une capture d’écran de cette page. » Un meilleur prompt d’utilisation de full-page-screenshot précise l’URL ou le contexte d’onglet, l’état d’authentification, la largeur de viewport, les besoins d’attente et le chemin de sortie :

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.

L’agent dispose ainsi d’assez d’informations pour choisir entre --list, la capture d’un onglet existant et le mode --url, sans devoir deviner.

FAQ de la skill full-page-screenshot

full-page-screenshot est-elle meilleure qu’un prompt de capture d’écran classique ?

Oui, lorsque le besoin porte sur une capture complète de la page plutôt que sur la seule fenêtre visible. Un prompt générique peut s’appuyer sur la capacité de capture d’écran disponible dans l’environnement, ce qui produit souvent uniquement l’écran courant. La skill full-page-screenshot fournit à l’agent un flux CDP précis, une structure de commande et une solution de repli pour les onglets déjà ouverts.

Les débutants peuvent-ils utiliser cette skill ?

Oui, s’ils savent installer des skills et exécuter Chrome avec le débogage distant activé. Les commandes sont simples, mais la mise en place est plus technique qu’une extension de navigateur. Les débutants devraient commencer par --check, puis --list, puis capturer un onglet existant avant d’essayer le mode URL.

Quand ne faut-il pas utiliser cette skill ?

Ne l’utilisez pas si vous avez besoin d’une surveillance planifiée par captures d’écran, d’une comparaison de rendu entre navigateurs, de diff de captures, d’OCR, d’export PDF ou d’une exécution cloud à grande échelle. Cette skill capture des screenshots PNG depuis Chrome/Chromium ; elle ne remplace pas les suites de tests Playwright, les plateformes de régression visuelle ni les APIs de capture d’écran hébergées.

Fonctionne-t-elle pour les workflows de Browser Automation ?

Oui. full-page-screenshot for Browser Automation convient très bien lorsqu’un agent a besoin d’une étape de capture déterministe après avoir navigué, s’être connecté, appliqué des filtres ou attendu un état d’interface. Elle est surtout utile comme outil de capture final dans un workflow navigateur plus large, et non comme framework complet de navigation ou de test à elle seule.

Comment améliorer la skill full-page-screenshot

Améliorer les entrées de full-page-screenshot

De meilleures entrées produisent de meilleures captures. Précisez l’état de la page, pas seulement son adresse : compte connecté, filtres sélectionnés, état d’une modale, largeur de viewport, éléments attendus une fois chargés et nom du fichier de sortie. Si la page est dynamique, nommez l’élément ou la section qui doit être visible avant la capture afin que l’agent sache quand une attente plus longue ou une confirmation manuelle est nécessaire.

Réduire les échecs de capture courants

Les blocages les plus fréquents sont le débogage distant de Chrome non activé, le choix du mode URL pour des pages nécessitant une connexion, une capture lancée avant la fin du chargement du contenu lazy-loaded et une largeur de viewport inadaptée. Corrigez-les en exécutant --check, en privilégiant le mode avec onglet existant pour les pages authentifiées, en augmentant --wait pour les SPAs publiques et en alignant --width sur la mise en page que vous voulez réellement inspecter.

Itérer après le premier PNG

Examinez le premier résultat pour repérer du contenu manquant en bas de page, des en-têtes sticky qui recouvrent des sections, des bandeaux de cookies, des images non chargées ou une mise en page responsive inattendue. Relancez ensuite avec une autre largeur, une attente plus longue ou un onglet déjà préparé. Si un bandeau de cookies ou une modale apparaît, fermez-le dans Chrome d’abord, puis capturez l’onglet existant plutôt que de compter sur une nouvelle URL ouverte en arrière-plan.

Lire le script avant de l’étendre

Si vous voulez personnaliser la skill, lisez scripts/full-page-screenshot.mjs avant de modifier les prompts. Le script contrôle la découverte des onglets, la largeur de viewport, le DPR, le comportement d’attente et la capture CDP. Les améliorations utiles peuvent inclure des messages d’erreur plus clairs, des stratégies d’attente supplémentaires, des conventions de nommage des sorties ou une gestion CSS optionnelle pour masquer les overlays sticky lorsque votre workflow l’autorise.