Ein Push schlägt fehl, weil eine 120 MiB große Modelldatei in den letzten Commit gerutscht ist. Ein Teammitglied unter Windows klont das Repository, und Git bricht mit "invalid path 'lib/aux.js'" ab. Ein Container beendet sich mit "exec /entrypoint.sh: no such file or directory", weil das Skript mit CRLF-Zeilenenden committet wurde. Eine .env-Datei, die in .gitignore steht, wurde committet, bevor es die Regel gab, und jeder Fork bekommt sie immer noch. Dieser Skill findet diese und die weiteren unten aufgeführten Hygienefehler im Repository und zeigt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner über den Repository-Ordner aus. Er durchläuft jede Datei außer Vendor- und generierten Ordnern (node_modules, vendor, dist, build, .venv und Ähnliches), verschachtelten Repositories und den Dateien, die .gitignore ignoriert, und liest .git/index direkt, ohne git auszuführen, um zu erfahren, welche Pfade Git verfolgt und wie groß sie sind. So erkennt er zwei Namen, die sich nur in der Groß-/Kleinschreibung unterscheiden, oder einen unter Windows reservierten Namen selbst in einem Checkout unter Windows oder macOS, in dem diese Dateien gar nicht auf der Festplatte existieren können, und so unterscheidet er ein Skript, das Git mit CRLF speichert (ein echtes Problem), von einem, das nur dieser Windows-Checkout wegen core.autocrlf mit CRLF hat (ein lokales Problem). Er berücksichtigt .gitattributes (text, eol, filter=lfs, conflict-marker-size) und .git/info/exclude. Er führt nie git oder den Code des Projekts aus und nutzt nie das Netzwerk. Er liefert BLOCK, REVIEW oder NOT FLAGGED mit Datei, Zeile, Begründung und einem sichereren Ansatz. Dateiinhalte und Secret-Werte werden nie ausgegeben.

Was geprüft wird

BLOCK (vor dem Ausliefern beheben)

• R01: in Dateien zurückgebliebene Merge-Konflikte (<<<<<<<, =======, >>>>>>>), nicht aber Überschriften-Unterstreichungen oder Beispiele in Markdown-Codeblöcken
• R02: Dateien über 100 MiB, die nicht mit Git LFS gespeichert sind
• R03: CRLF-Zeilenenden in Shell-Skripten, Shell-Startdateien, sh/bash/node-Dateien mit #! und Dateien mit #! ohne Endung (bin/deploy, Git-Hooks), wenn Git sie so speichert, .gitattributes eol=crlf setzt oder kein .git/index zum Vergleich vorhanden ist
• R04: Pfade, die sich nur in der Groß-/Kleinschreibung oder der Unicode-Normalisierung unterscheiden, oder eine Datei, die wie ein Ordner in anderer Schreibweise heißt (der Befund weist darauf hin, dass ein Projekt, das nie unter Windows oder macOS ausgecheckt wird, sie behalten kann)
• R05: Namen, die Windows nicht anlegen kann: CON, PRN, AUX, NUL, COM1-9, LPT1-9 (auch aux.js, nul.txt), < > : " | ? * \ und Steuerzeichen, Namen, die auf ein Leerzeichen oder einen Punkt enden
• R06: Dateien mit Zugangsdaten, die Git verfolgt: private SSH-Schlüssel, .ppk, .p12, .pfx, .jks, .keystore, .kdbx, AuthKey_*.p8, private PEM-Schlüssel, JSON-Schlüssel von Dienstkonten, .git-credentials, .netrc, terraform.tfstate sowie env-Dateien mit Secret-Werten, die .local heißen oder von .gitignore ignoriert werden (in Testordnern siehe R22)

REVIEW (vor dem Release prüfen)

• R11: Dateien über 50 MiB, die nicht mit Git LFS gespeichert sind
• R12: gemischte CRLF- und LF-Zeilenenden ohne .gitattributes-Regel für die Datei
• R13: eine UTF-8-Byte-Order-Mark in JSON, PHP, Shell-Skripten und Dateien mit #!
• R14: Pfade über 200 Zeichen ab dem Repository-Stamm oder Namen über 255 Byte
• R15: Symlinks, die aus dem Repository hinauszeigen
• R16: .sh-Dateien ohne #!-Zeile in Zeile 1
• R17: Überbleibsel wie .orig, .rej und _BASE_/_LOCAL_/_REMOTE_/_BACKUP_ von Merge-Tools
• R18: Datenbank-Dumps und lokale Datenbanken, die Git verfolgt (.sql.gz, .dump, dump.sql, dump.rdb, .bson, .sqlite3, .mdf)
• R19: Dateien, die Git verfolgt, obwohl .gitignore oder .git/info/exclude sie ignoriert (ein Befund pro ignoriertem Ordner)
• R20: eine LICENSE-Datei, aber keine SECURITY.md im Stammverzeichnis, in docs/ oder .github/
• R21: Shell-Skripte mit CRLF nur in diesem Checkout: Git speichert sie mit LF (core.autocrlf=true unter Windows), daher sind Push und Linux-CI in Ordnung, WSL- und Docker-Builds aus dem Ordner aber nicht
• R22: Testschlüssel und Keystores in den Ordnern test, spec und fixtures sowie Truststores (truststore.jks, cacerts): Vergewissern Sie sich, dass sie nirgends produktiv verwendet werden

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek) mit einem Leser für das Indexformat von Git (Versionen 2, 3 und 4, SHA-1- und SHA-256-Repositories, geteilte Indizes, verknüpfte Worktrees)
• Ein Regelleitfaden mit Begründung, sichererem Ansatz und offizieller Quelle für jede Regel
• Ein riskantes und ein sicheres Beispielprojekt sowie der echte Bericht, den der Scanner für das riskante Projekt erzeugt (das Beispiel zeigt sechs der Regeln; die anderen brauchen Dinge, die ein ZIP nicht transportieren kann, etwa eine 100-MiB-Datei, einen Symlink oder einen .git-Ordner)

Grenzen

Er liest die Dateien in ihrem aktuellen Zustand und die Liste der verfolgten Pfade in .git/index. Git-Historie, andere Branches und gespeicherte Objekte werden nicht gelesen, daher wird eine Datei, die in einem späteren Commit gelöscht wurde, aber noch in der Historie steckt, nicht gefunden. Ohne .git-Ordner (ein heruntergeladenes Quellarchiv) laufen die Regeln zu verfolgten Dateien (R06, R18, R19, R22) nicht, und ein CRLF-Skript wird als R03 gemeldet, weil die committete Kopie nicht verglichen werden kann. Eine globale Excludes-Datei, globale Attribute und Dateimodi wie das Ausführungsbit werden nicht geprüft. Er durchsucht den Dateitext nicht nach Secrets. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 28 Dateien: SKILL.md, der Scanner in scripts/ (8 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Ansatz) und examples/ (19 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

Verwendung: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie dann Ihren Agenten, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.