Install
npx skills add squirrelscan/skillsÀ qui cela s’adresse
Ce guide s’adresse à qui confie les audits de site à un agent et accepte que chaque skill soit pilotée par le squirrel CLI. Officiellement, ce sont des skills d’audit de site, des plugins et du MCP pour agents, dans un seul dépôt :
https://github.com/squirrelscan/skills
Les matériaux actuels n’explicitent que deux skills. squirrelscan pilote le CLI : installation, connexion, lancer des audits, publier des rapports, crédits, clés d’API, réglage MCP, configuration et dépannage. Notes sur
https://github.com/squirrelscan/skills/blob/main/skills/squirrelscan/SKILL.md
audit-website est la boucle de correction : auditer un site, relier les constats au code, modifier par lots, puis ré-auditer jusqu’à ce que le score s’améliore. Notes sur
https://github.com/squirrelscan/skills/blob/main/skills/audit-website/SKILL.md
Cela convient si le CLI peut être installé et si seuls des sites que l’on a le droit d’inspecter sont audités. Cela ne convient pas si le CLI n’est pas sur PATH, ou si l’on veut les skills comme de simples documents sans CLI.
Réussir un premier essai en 3 minutes
Suivre uniquement le chemin officiel recommandé.
Préalable : cette machine peut exécuter npx, et squirrel CLI est installé et sur PATH. Les matériaux disent que chaque skill pilote ce CLI, mais ne donnent pas de commande d’installation du CLI lui-même. Si squirrel n’est pas encore sur PATH, laisser d’abord la skill squirrelscan gérer l’installation et la connexion ; ne pas sauter au scan.
Emplacement d’installation : géré par npx skills add. Les matériaux n’écrivent pas le point d’arrivée du dossier de skill ; ne pas inventer un chemin absent.
Copier et exécuter :
npx skills add squirrelscan/skills
Succès : la commande se termine normalement. D’abord une confirmation en lecture seule : demander à l’agent de vérifier si squirrel est sur PATH et d’expliquer les étapes d’un audit, sans scanner d’URL, sans publier de rapport et sans modifier le code. S’il peut reformuler qu’il faut le CLI et que connexion / audit / publication sont des actions séparées, la skill est chargée.
Avant un vrai scan, confirmer l’URL cible et le droit d’auditer. Scanner, publier un rapport et écrire du code ont des effets.
Cas d’usage
Cas 1 : ne piloter que le CLI ; se connecter d’abord, puis décider d’auditer. Correspond à squirrelscan. Convient quand aucun scan n’a encore tourné et que l’on veut seulement confirmer installation, connexion, configuration et crédits. Succès : le CLI est utilisable et l’état de connexion est clair. Les matériaux mentionnent aussi le MCP hébergé :
https://mcp.squirrelscan.com/mcp
Il utilise streamable-http et peut utiliser OAuth ou une clé Authorization: Bearer sq_... ; en local c’est squirrel mcp. Le premier essai n’a pas besoin d’attacher MCP. Ne pas inventer une clé complète.
Cas 2 : après l’audit, relier au code, mais s’arrêter à la correspondance. Correspond à la boucle de correction de audit-website. Convient quand le CLI tourne déjà et que l’on veut voir dans quels fichiers tombent les problèmes d’un site confirmé. Auditer d’abord et ne demander que la correspondance constats-vers-code ; interdire explicitement les modifications par lots. Succès : la correspondance problème–fichier est visible et le dépôt n’a pas encore changé. Après confirmation du périmètre du correctif, autoriser les lots et un nouveau test. Les matériaux ne donnent ni seuil de score ni taille de lot.
Limites d’usage
Les matériaux actuels ne prouvent que les deux skills ci-dessus et une commande d’installation npx. Ne pas inventer d’autres noms de skills ni passer à un installateur jamais apparu. Les matériaux ne nomment aucun client obligatoire.
Ne pas appeler ces skills sans le CLI. Publier un rapport envoie les résultats hors de cette machine ; modifier le code écrit le dépôt. Vérifier d’abord, puis autoriser. Le préfixe de clé dans les matériaux est sq_... ; ne pas inventer une clé d’exemple. Pour le reste, suivre le dépôt officiel :
https://github.com/squirrelscan/skills