Un push échoue parce qu'un fichier de modèle de 120 Mio s'est glissé dans le dernier commit. Un collègue sous Windows clone le dépôt et git s'arrête avec "invalid path 'lib/aux.js'". Un conteneur se termine avec "exec /entrypoint.sh: no such file or directory" parce que le script a été commité avec des fins de ligne CRLF. Un fichier .env listé dans .gitignore a été commité avant que la règle n'existe, et chaque fork le récupère encore. Ce skill détecte ces erreurs et les autres problèmes d'hygiène de dépôt ci-dessous, et vous indique comment corriger chacun d'eux.

Votre agent exécute un scanner sur le dossier du dépôt. Il parcourt tous les fichiers sauf les dossiers de dépendances embarquées et les dossiers générés (node_modules, vendor, dist, build, .venv et similaires), les dépôts imbriqués et les fichiers ignorés par .gitignore, et il lit directement .git/index, sans exécuter git, pour savoir quels chemins git suit et quelle est leur taille. C'est ainsi qu'il repère deux noms qui ne diffèrent que par la casse, ou un nom réservé de Windows, même dans une copie de travail sous Windows ou macOS où ces fichiers ne peuvent pas exister sur le disque, et qu'il distingue un script que git stocke en CRLF (un vrai problème) d'un script qui n'est en CRLF que dans cette copie Windows à cause de core.autocrlf (un problème local). Il respecte .gitattributes (text, eol, filter=lfs, conflict-marker-size) et .git/info/exclude. Il n'exécute jamais git ni le code du projet 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. Le contenu des fichiers et les valeurs secrètes ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• R01 : conflits de merge laissés dans les fichiers (<<<<<<<, =======, >>>>>>>), hors soulignements de titres et exemples dans des blocs de code Markdown
• R02 : fichiers de plus de 100 Mio qui ne sont pas stockés avec Git LFS
• R03 : fins de ligne CRLF dans les scripts shell, les fichiers de démarrage du shell, les fichiers #! sh/bash/node et les fichiers #! sans extension (bin/deploy, hooks git) lorsque git les stocke ainsi, que .gitattributes définit eol=crlf ou qu'il n'y a pas de .git/index pour comparer
• R04 : chemins qui ne diffèrent que par la casse ou la normalisation Unicode, ou un fichier nommé comme un dossier avec une autre casse (le résultat précise qu'un projet jamais extrait sous Windows ou macOS peut les conserver)
• R05 : noms que Windows ne peut pas créer : CON, PRN, AUX, NUL, COM1-9, LPT1-9 (aussi aux.js, nul.txt), < > : " | ? * \ et caractères de contrôle, noms se terminant par une espace ou un point
• R06 : fichiers d'identifiants suivis par git : clés privées SSH, .ppk, .p12, .pfx, .jks, .keystore, .kdbx, AuthKey_*.p8, clés privées PEM, clés JSON de comptes de service, .git-credentials, .netrc, terraform.tfstate, et fichiers env contenant des valeurs secrètes nommés .local ou ignorés par .gitignore (dans les dossiers de test, voir R22)

REVIEW (à vérifier avant la publication)

• R11 : fichiers de plus de 50 Mio qui ne sont pas stockés avec Git LFS
• R12 : fins de ligne CRLF et LF mélangées sans règle .gitattributes pour le fichier
• R13 : une marque d'ordre des octets (BOM) UTF-8 dans des fichiers JSON, PHP, des scripts shell et des fichiers #!
• R14 : chemins de plus de 200 caractères depuis la racine du dépôt, ou noms de plus de 255 octets
• R15 : liens symboliques qui pointent hors du dépôt
• R16 : fichiers .sh sans ligne #! en ligne 1
• R17 : restes .orig, .rej et _BASE_/_LOCAL_/_REMOTE_/_BACKUP_ d'outils de merge
• R18 : dumps de bases de données et bases de données locales suivis par git (.sql.gz, .dump, dump.sql, dump.rdb, .bson, .sqlite3, .mdf)
• R19 : fichiers suivis par git alors que .gitignore ou .git/info/exclude les ignore (un résultat par dossier ignoré)
• R20 : un fichier LICENSE mais aucun SECURITY.md à la racine, dans docs/ ou dans .github/
• R21 : scripts shell en CRLF uniquement dans cette copie de travail : git les stocke en LF (core.autocrlf=true sous Windows), donc le push et la CI Linux fonctionnent, mais pas les builds WSL et Docker lancés depuis le dossier
• R22 : clés de test et keystores dans les dossiers test, spec et fixtures, et truststores (truststore.jks, cacerts) : vérifiez qu'ils ne sont utilisés nulle part en conditions réelles

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement), avec un lecteur du format d'index de git (versions 2, 3 et 4, dépôts SHA-1 et SHA-256, index scindés, worktrees liés)
• Un guide des règles avec la raison, l'approche plus sûre et la source officielle de chaque règle
• Un projet d'exemple risqué et un projet sûr, ainsi que le rapport réel produit par le scanner sur le projet risqué (l'exemple illustre six des règles ; les autres nécessitent des éléments qu'un ZIP ne peut pas transporter, comme un fichier de 100 Mio, un lien symbolique ou un dossier .git)

Limites

Il lit les fichiers dans leur état actuel et la liste des chemins suivis dans .git/index. L'historique git, les autres branches et les objets stockés ne sont pas lus : un fichier supprimé dans un commit ultérieur mais toujours présent dans l'historique n'est donc pas détecté. Sans dossier .git (une archive de sources téléchargée), les règles sur les fichiers suivis (R06, R18, R19, R22) ne s'exécutent pas, et un script en CRLF est signalé en R03 car la copie commitée ne peut pas être comparée. Un fichier d'exclusions global, les attributs globaux et les modes de fichier comme le bit d'exécution ne sont pas vérifiés. Il ne recherche pas de secrets dans le texte des fichiers. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP contenant 28 fichiers : SKILL.md, le scanner dans scripts/ (8 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (19 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.