"outputs": ["dist/**", ".env.production"] copie vos secrets de production dans chaque artefact de cache, et une tâche de déploiement sans "cache": false peut être rejouée depuis le cache au lieu d'être exécutée : Turborepo affiche les anciens journaux et signale un succès alors que rien n'a été déployé. Cette compétence détecte ces erreurs et les autres erreurs de cache de monorepo ci-dessous avant votre prochaine build, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur turbo.json et turbo.jsonc, nx.json, project.json, les fichiers package.json qui utilisent turbo, nx ou lerna (scripts, dépendances et cibles nx), les workflows CI et les Dockerfiles qui exécutent turbo ou nx, et le code JavaScript et TypeScript d'un espace de travail Turborepo (la sortie de build est ignorée). Il lit le JSON avec commentaires, connaît les valeurs par défaut actuelles (Turborepo met en cache chaque tâche et s'exécute en mode d'environnement strict ; Nx ne met en cache que les cibles marquées "cache": true), fusionne les fichiers turbo.json des packages avec celui de la racine au-dessus d'eux, connaît les variables que Turborepo transmet à chaque tâche et les préfixes de framework qu'il déduit, distingue les tâches en lecture seule comme lint:migrations ou release:notes des véritables déploiements, et traite les références de secrets CI et les espaces réservés commentés pour ce qu'ils sont. Il n'exécute jamais turbo, nx 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 qu'il vérifie

BLOCK (à corriger avant la mise en production)

• M01 : fichiers .env et autres fichiers secrets (.pem, .key, .npmrc, clés SSH) dans les outputs de tâches, où chaque copie de cache et chaque téléversement vers le cache distant les conserve ensuite
• M02 : tâches de déploiement, de publication, de release et de migration qui peuvent être servies depuis le cache (pas de "cache": false dans Turborepo, "cache": true ou cacheableOperations dans Nx) ; les tâches en lecture seule comme lint:migrations, migrations:check ou release:notes ne sont pas signalées
• M03 : TURBO_TOKEN, jetons Nx Cloud, clé de signature du cache distant ou clé secrète du cache S3 de Nx écrits dans des lignes actives de fichiers CI, Dockerfiles, scripts package.json ou nx.json

REVIEW (à vérifier avant la publication)

• M11 : tâches de build dans le turbo.json racine sans outputs
• M12 : variables d'environnement lues par le code (y compris dans des littéraux de gabarit) qu'aucun turbo.json ne déclare, une détection par variable
• M13 : mode d'environnement laxiste
• M14 : un cache distant Turborepo auto-hébergé (remoteCache.apiUrl, TURBO_API) sans vérification de signature ; le Remote Cache Vercel configuré comme le montre la documentation Turborepo n'est pas signalé
• M15 : la clé pipeline de Turborepo 1.x
• M16 : entrées de tâches sans $TURBO_DEFAULT$
• M17 : un jeton d'accès Nx Cloud dans nx.json
• M18 : les caches obsolètes Nx S3, GCS, Azure et shared-fs (CVE-2025-36852)
• M19 : un jeton de cache à l'apparence réelle dans une ligne commentée de CI ou de Dockerfile (les espaces réservés comme your-token sont acceptés)

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 la source officielle de chaque règle
• Des dépôts d'exemple à risque et sûrs (une boutique Turborepo 2, une application Turborepo 1.x et une plateforme Nx), ainsi que le rapport réel produit par le scanner sur les exemples à risque

Limites

Il lit chaque fichier tel qu'il est écrit : les tâches déduites par les plugins Nx, les paramètres conservés dans les tableaux de bord Nx Cloud ou Vercel (portées des jetons, niveaux d'accès de l'espace de travail) et le cache distant que Vercel active pour ses propres builds ne sont pas vus. Les variables d'environnement sont comparées sur l'ensemble des fichiers turbo.json du scan, pas par tâche, l'accès aux variables via des fonctions utilitaires n'est pas suivi, la sortie de build dans des dossiers que ne couvre aucun glob d'outputs, champ main ou nom connu est lue comme du code source, et un fichier .env repéré seulement par un glob d'output large comme ** n'est pas signalé. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP avec 29 fichiers : SKILL.md, le scanner dans scripts/ (6 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre), et examples/ (20 fichiers d'exemple plus report.md, le rapport réel produit par le scanner sur l'exemple à risque).

Comment l'utiliser : Il s'agit d'une compétence d'agent : un dossier avec un fichier SKILL.md et des scripts Python qu'un agent de codage IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier de compétences 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 lisent uniquement vos fichiers : aucun accès réseau, et rien n'est envoyé où que ce soit.