"start": "deno serve -A main.ts" désactive le bac à sable de Deno pour chaque dépendance que charge votre serveur, et un seul --unsafely-ignore-certificate-errors dans une tâche permet à n'importe qui sur le réseau de remplacer les modules que Deno télécharge. Ce skill repère ces erreurs et onze autres erreurs de configuration Deno avant le déploiement, et vous explique comment corriger chacune.

Votre agent lance un scanner sur deno.json et deno.jsonc (les commentaires et les virgules finales sont acceptés), les import maps, deno.lock, les scripts de package.json, .gitignore, les commandes deno des Dockerfile, fichiers Compose, unités systemd, Procfile et scripts shell, ainsi que sur les imports et les appels à Deno.Command de votre code TypeScript et JavaScript. Il lit les commandes deno comme le fait deno : les options placées après le nom du script appartiennent au script, -qA contient -A, et --allow-run=git est une liste alors que --allow-run n'en est pas une. Les constats sur les permissions concernent les commandes de production (tâches start et serve, CMD et ENTRYPOINT des Dockerfile, commandes Compose, ExecStart de systemd, Procfile, deno compile), pas les tâches dev, test, build ou --watch. Il n'exécute jamais deno, vos tâches ou votre code. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• D01: modules chargés en http simple dans les imports ou scopes de deno.json, les import maps, les instructions import, deno.lock ou les commandes deno (localhost est accepté)
• D02: --unsafely-ignore-certificate-errors pour tous les hôtes ou pour des hôtes autres que localhost
• D03: Deno.Command ou Deno.run qui lance sh, bash, cmd ou PowerShell avec une chaîne de commande construite à partir de Deno.args, Deno.env, de données de requête ou d'un paramètre de fonction
• D04: DENO_AUTH_TOKENS, DENO_KV_ACCESS_TOKEN et d'autres jetons écrits dans des Dockerfile, Compose, unités systemd, tâches et scripts, ainsi que des identifiants dans les URL de modules

REVIEW (à vérifier avant la publication)

• D11: -A / --allow-all sur les commandes de production, ou "all": true dans un ensemble de permissions de deno.json
• D12: --allow-run sans liste ou pour deno, un shell ou un interpréteur, et --allow-ffi (options ou ensembles de permissions de deno.json)
• D13: --allow-write sans liste de chemins
• D14: "lock": false, --no-lock ou deno.lock ignoré dans le .gitignore d'un projet Deno
• D15: imports https sans version, étiquette ni commit, et entrées jsr: ou npm: de l'import map sans version ou avec latest
• D16: scripts d'installation npm autorisés pour tous les paquets (--allow-scripts sans liste, "allowScripts": true)
• D17: --inspect, --inspect-brk ou --inspect-wait liés à 0.0.0.0 ou à une autre adresse hors loopback
• D18: une chaîne de commande shell construite à partir d'autres valeurs ou conservée dans une variable (une version, un chemin, l'argument d'une fonction utilitaire)
• D19: "minimumDependencyAge": 0, qui désactive le délai d'attente de 24 heures de Deno avant l'installation d'une version npm ou JSR tout juste publiée

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et le lien vers la documentation officielle de Deno pour chaque règle
• Un projet d'exemple risqué et un projet sûr, ainsi que le vrai rapport produit par le scanner sur le projet risqué

Limites

Il lit chaque fichier séparément : une tâche qui en appelle une autre, un ensemble de permissions choisi avec -P, les commandes exécutées par ssh et les valeurs des fichiers .env ne sont pas suivis, et les chaînes de commande shell ne sont suivies qu'à travers une variable du même fichier. Les options --allow-net, --allow-read, --allow-env et --allow-sys sans restriction ne sont pas signalées, car la plupart des serveurs en ont besoin et les exemples Docker officiels de Deno les utilisent. Les workflows GitHub Actions, les Makefile et les manifestes Kubernetes ne sont pas lus. La tâche start officielle de Fresh et le guide Docker de Fresh utilisent -A et --allow-scripts pour tous les paquets ; ils sont signalés en REVIEW volontairement. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP de 20 fichiers : SKILL.md, le scanner dans scripts/ (5 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (12 fichiers d'exemple plus report.md, la vraie sortie du scanner sur l'exemple risqué).

Mode d'emploi : Il s'agit d'un skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier de skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien installer. Ils ne font que lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.