Eine für CI ins Repository kopierte profiles.yml, die noch das Warehouse-Passwort enthält, oder eine packages.yml, die ein privates Paket von https://[email protected] installiert, gibt jedem mit Lesezugriff auf das Repository Zugang zu Ihrem Warehouse oder GitHub. Unauffälligere Fehler verfälschen dagegen die Zahlen: Ein inkrementelles Modell ohne unique_key speichert verspätete Zeilen doppelt, und ein Modell ohne unique-Test auf seinem Schlüssel lässt fehlerhafte Joins Zeilen vervielfachen. Dieser Skill findet diese und die unten genannten weiteren dbt-Fehler und zeigt, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner in Ihrem dbt-Projekt aus: für dbt_project.yml, jede profiles.yml im Ordner (auch .dbt/profiles.yml), packages.yml, dependencies.yml sowie die SQL-Modelle und YAML-Eigenschaftsdateien in Ihren model-paths. Er versteht dbt-Jinja (ref(), source(), config(), env_var(), is_incremental()), sowohl tests: als auch data_tests:, freshness und loaded_at_field unter config: (dbt 1.9 und 1.10), Konfigurationen in config(), einer Eigenschaftsdatei oder einem Ordnerblock in dbt_project.yml sowie Ihre .gitignore. Er folgt dem offiziellen dbt-Stilleitfaden und meldet daher weder Import-CTEs noch select from final und select aus einem ref(). Er führt weder dbt aus noch verbindet er sich mit Ihrem Warehouse. Er liefert BLOCKIEREN, PRÜFEN oder NICHT MARKIERT, jeweils mit Datei, Zeile, Begründung und sichererem Vorgehen. Geheimnisse werden niemals ausgegeben.

Was geprüft wird

BLOCKIEREN (vor der Veröffentlichung beheben)

• D01: direkt eingetragene Passwörter, Token, private Schlüssel, keyfile_json, Client-Geheimnisse, Refresh-Token und geheime AWS-Schlüssel in profiles.yml (auch echt wirkende Geheimnisse als Standardwerte für env_var())

• D02: eine profiles.yml mit direkt eingetragenen Zugangsdaten in einem Git-Repository, die weder durch eine .gitignore-Regel noch durch einen Eintrag in .git/info/exclude abgedeckt ist

• D03: Git-Token oder Passwörter in URLs von packages.yml und dependencies.yml sowie schlüsselartige geheime Variablen in dbt_project.yml

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

• D11: Modelle ohne das Testpaar unique + not_null auf einer Schlüsselspalte (oder ganz ohne Eigenschaftsdatei); Time-Spine-Modelle werden übersprungen

• D12: ein abschließendes select (oder ein einzelnes t.), das sämtliche Rohspalten einer source() oder einer benannten Tabelle direkt durchreicht

• D13: Quellen, deren Tabellen keine freshness mit warn_after oder error_after haben

• D14: ausgeschriebenes database.schema.table oder schema.table statt ref() oder source()

• D15: inkrementelle Modelle ohne unique_key (append, insert_overwrite, microbatch und Databricks replace_where sind zulässig)

• D16: env_var()-Ersatzwerte in profiles.yml mit einem bekannten Standardpasswort wie postgres oder changeme

Im Lieferumfang

• Der Scanner (Python 3.9+, nur Standardbibliothek)

• Ein Regelhandbuch mit Begründung und sichererem Vorgehen zu jeder Regel

• Ein unsicheres und ein sicheres dbt-Beispielprojekt sowie der tatsächliche Scanner-Bericht für das unsichere Beispiel

Grenzen

Der Scanner liest Dateien so, wie sie vorliegen. Jinja wird nicht gerendert; durch Makros oder Schleifen erzeugte Modelle, über var() oder env_var() gesetzte Konfigurationen und Adapter-Standardwerte werden daher nicht ausgewertet. Eine profiles.yml in ~/.dbt/ wird nur geprüft, wenn Sie sie angeben; eine globale Git-Ausschlussdatei wird nicht gelesen. Python-Modelle, Seeds, Snapshots, Analysen, einzelne SQL-Tests und installierte Pakete in dbt_packages/ werden nicht geprüft. Eine primary_key-Bedingung allein zählt nicht als Schlüsseltest, da die meisten Warehouses sie nicht durchsetzen. NICHT MARKIERT ist keine Garantie.

Archivinhalt

Eine ZIP-Datei mit 29 Dateien: SKILL.md, der Scanner in scripts/ (6 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Vorgehen) und examples/ (20 Beispieldateien sowie report.md, die tatsächliche Scanner-Ausgabe für das unsichere 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. Entpacken Sie das Archiv in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie Ihren Agenten anschließend, Ihr 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 nur Ihre Dateien: kein Netzwerkzugriff, und es wird nichts versendet.