Depuis le 2026-09-21, CircleCI rejette les configurations en version 2.0, les filtres de branche comme /^(?!main).*/ et les paramètres utilisés mais jamais déclarés : le pipeline échoue donc avant le démarrage du moindre job. Un token Sentry collé sous environment: est lisible par toute personne ayant accès au projet, et un job de déploiement avec un contexte aws-production qui s'exécute sur toutes les branches remet ces identifiants à quiconque peut pousser une branche. Ce skill détecte ces erreurs et les autres erreurs CircleCI ci-dessous, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur chaque fichier YAML de .circleci/ (config.yml, configurations de continuation pour les setup workflows et la dynamic config, fragments de configuration empaquetés) ou sur un fichier de configuration que vous indiquez. Il comprend les orbs (du registre, par URL et inline), les executors, jobs, commands, workflows, contextes, jobs d'approbation, filtres, paramètres de pipeline et valeurs << >>, les ancres YAML, et rattache les blocs run: | à leurs vrais numéros de ligne. Il connaît les références $NAME, les paramètres d'orb env_var_name, les mots de passe de bases de données de test dans les conteneurs de service (y compris lorsqu'une commande les réutilise) et des paramètres comme OIDC_TOKEN_AUDIENCE: sts.amazonaws.com, pour ne pas les signaler comme des fuites. Les règles liées à une échéance CircleCI sont comparées à la date du jour. Il n'exécute jamais de job ni la CircleCI CLI, et n'utilise jamais le réseau. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre, et ajoute le lien vers la page CircleCI derrière chaque règle qui en a une. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• C01 : mots de passe, tokens et clés écrits dans la configuration (valeurs environment, docker auth, paramètres d'orbs et de jobs, valeurs par défaut des paramètres, curl -u, en-têtes Authorization, docker login -p, un littéral passé par echo à docker login --password-stdin, npm _authToken, mots de passe dans des URL, formats de tokens GitHub, AWS, CircleCI, npm, Slack et autres, clés privées)
• C02 : scripts ou binaires téléchargés en http:// ou avec les vérifications TLS désactivées, puis exécutés sans checksum
• C03 : orbs référencés en @volatile ou avec une version dev: (sauf l'orb qu'un dépôt d'orb publie, dans son propre pipeline de test)
• C04 : configuration que CircleCI ne compile plus : version autre que 2.1, filtres regex avec lookarounds négatifs, quantificateurs possessifs ou références arrière, paramètres non déclarés, paramètres de pipeline dans des orbs inline, noms de jobs contenant des deux-points ou des parenthèses, branches sur un job, resource_class à l'intérieur de machine, un config.yml vide et, à partir du 2026-12-14, les avertissements du validateur de C19
• C05 : executors supprimés : Ubuntu 14.04/16.04 et images machine datées 20.04/22.04 supprimées, versions de Xcode supprimées (16.2.0 et 26.2.0 à partir du 2026-12-07), macOS Intel et classes de ressources M1/M2

REVIEW (à vérifier avant la publication)

• C11 : orbs partenaires et communautaires épinglés uniquement sur une version majeure ou mineure, et orbs par URL sur une branche au lieu d'un commit
• C12 : images Docker sans tag ou en latest, images machine sur edge
• C13 : noms de branches, tags, messages de commit, titres de pull requests, corps de webhooks et paramètres de pipeline de type string insérés dans des commandes run (y compris via un paramètre de job)
• C14 : add_ssh_keys sans fingerprints
• C15 : anciennes images circleci/, images machine circleci/classic et Ubuntu 20.04, Xcode 16.2.0 et 26.2.0 avant leur suppression le 2026-12-07, machine: true sans image
• C16 : curl | bash, bash <(curl ...) et téléchargement puis exécution en HTTPS sans vérification de checksum ni de signature
• C17 : jobs de deploy, release, publish ou de signature avec un contexte, qui s'exécutent sur toutes les branches, sans filtre, job d'approbation ni condition de workflow (les déploiements non-prod, preview, staging et dev ne sont pas comptés)
• C18 : valeurs de pipeline retirées : pipeline.trigger_parameters.circleci.*, pipeline.trigger_parameters.github_app.*, pipeline.trigger_source, $CIRCLE_COMPARE_URL
• C19 : avertissements du validateur de configuration qui bloquent les pipelines à partir du 2026-12-14 (valeur par défaut d'un enum absente de cet enum, étape run sans commande, when à côté d'une étape, workflow avec à la fois when et unless, nom de command invalide, requires vide, docker: ou steps: nus, parallelism ou méthode de checkout incorrects, arguments de job ou de command non déclarés, type de job généré par template) ; signalés en C04 à partir de ce jour

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 CircleCI de chaque règle (C13 n'en a pas : aucune page CircleCI ne traite ce point)
• Un exemple risqué et un exemple sûr (une boutique en ligne avec des jobs de déploiement web, iOS et AWS), ainsi que le rapport réel produit par le scanner sur l'exemple risqué

Limites

Chaque fichier est lu tel qu'il est écrit. Les paramètres conservés hors du dépôt ne sont pas visibles : variables d'environnement du projet, restrictions des contextes, transmission de secrets aux pull requests issues de forks, listes d'orbs autorisés, politiques de configuration et protection des branches. Le code source des orbs n'est pas téléchargé, donc ce qu'un orb fait de ses paramètres n'est pas suivi. Les listes d'images, de versions de Xcode et de classes de ressources supprimées suivent le changelog de CircleCI jusqu'en novembre 2026. Quelques extraits de la documentation officielle sont signalés volontairement (par exemple un echo de << pipeline.git.branch >> ou d'un paramètre de pipeline de type string dans une étape run) ; C13 repose sur la façon dont CircleCI écrit les valeurs << >> dans la configuration, car aucune page CircleCI ne met en garde à ce sujet. L'exemple risqué ne contient aucun résultat C19, car C19 devient C04 le 2026-12-14. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP contenant 11 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/ (2 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Utilisation : 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 des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi de manière autonome avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.