Du legst eine .npmignore mit nur einer Zeile an: test/. npm liest daraufhin deine .gitignore nicht mehr, und das nächste npm publish liefert .env.production mit aus. In deiner .dockerignore steht *.log, doch Docker wendet das Muster nur im Stammverzeichnis an. Deshalb landet logs/ trotzdem im Image. Dieser Skill findet diese und weitere Fälle, in denen Ignore-Regeln unbemerkt versagen, und erklärt dir, wie du jeden davon behebst.

Dein Agent führt einen Scanner für den Projektordner aus. Er ermittelt, was jedes Werkzeug tatsächlich tun würde: Git (jede .gitignore, auch verschachtelte und übergeordnete, .git/info/exclude, Negation, Verankerung, reine Ordnermuster und die Liste bereits verfolgter Dateien in .git/index, deren Verfolgung .gitignore niemals beendet), Docker (die .dockerignore im Stamm des Build-Kontexts oder die Dockerfile-spezifische Datei, nur im Stamm passende Muster, ** und Wiedereinschlüsse mit !, abgeglichen mit jedem COPY und ADD) sowie npm (die "files"-Liste, .npmignore als Ersatz für .gitignore, Workspaces, immer und niemals enthaltene Dateien). Dateien mit Geheimnissen werden anhand ihres Inhalts erkannt, nicht nur anhand ihres Namens: Eine .env-Datei wird nur gemeldet, wenn sie einen echten geheimen Wert enthält. Er führt weder git noch docker oder npm aus. Das Ergebnis lautet BLOCK, REVIEW oder NOT FLAGGED, jeweils mit Datei, Zeile, Begründung und einem sichereren Vorgehen. Geheimnisse werden nie ausgegeben.

Was geprüft wird

BLOCKIEREN (vor der Auslieferung beheben)

• G01: Dateien mit Geheimnissen, die Git einchecken würde oder bereits verfolgt (.env mit Schlüsseln, private Schlüssel, .p12/.jks-Schlüsselspeicher, Dienstkonto-JSON, Tokens in .npmrc/.pypirc/.netrc, Terraform-Zustand, Rails master.key)

• G02: Dateien mit Geheimnissen oder der .git-Ordner, die per COPY oder ADD in ein Docker-Image kopiert werden

• G03: Dateien mit Geheimnissen, die npm publish einschließen würde

PRÜFEN (vor der Veröffentlichung prüfen)

• G11: nicht ignorierte node_modules, virtuelle Umgebungen, Caches und Build-Ausgaben

• G12: COPY . ohne .dockerignore oder vom Host kopierte Abhängigkeitsordner

• G13: .dockerignore-Muster, die nur im Stamm des Build-Kontexts passen

• G14: !-Zeilen, die Namen von Dateien mit Geheimnissen wieder einschließen

• G15: nicht ignorierte Dateien über 50 MB, SQLite-Datenbanken, Datenbank-Dumps und Logs

• G16: Logs, Coverage-Ausgaben und alte Tar-Archive, die npm publish einschließen würde

• G17: nicht ignorierte .DS_Store, Thumbs.db, Swap-Dateien, *.orig und IDE-Workspace-Dateien

• G18: Dateien mit Geheimnissen in Test-, Fixture- und Beispielordnern (oft wegwerfbare Testschlüssel, daher bitte prüfen)

Im Lieferumfang

• Der Scanner (Python 3.9+, nur Standardbibliothek)

• Ein Regelhandbuch mit Begründung und sichererem Vorgehen für jede Regel

• Ein riskantes und ein sicheres Beispielprojekt sowie der tatsächliche Scannerbericht zum riskanten Projekt

Grenzen

Er liest die Dateien auf dem Datenträger. Deine globale Git-Ausschlussdatei, nur in docker-compose oder CI-Befehlen festgelegte Build-Kontexte und während eines Builds erzeugte Dateien werden nicht nachverfolgt. Ordner wie node_modules und dist werden aufgelistet, aber nicht durchsucht. NOT FLAGGED ist keine Garantie.

Inhalt

Ein ZIP-Archiv mit 38 Dateien: SKILL.md, der Scanner unter scripts/ (5 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Vorgehen) und examples/ (30 Beispieldateien sowie report.md, die tatsächliche Scannerausgabe zum riskanten Beispiel).

Anwendung: Dies ist ein Agenten-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Programmieragent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacke das Archiv in den Skills-Ordner deines Agenten (für Claude Code: ~/.claude/skills/). Bitte deinen Agenten anschließend, dein Projekt zu prüfen. Die Skripte lassen sich auch eigenständig mit Python 3.9 oder neuer ausführen, ohne zusätzliche Installation. Sie lesen ausschließlich deine Dateien: kein Netzwerkzugriff und keine Datenübertragung.