Claude Code Git-Hooks verhindern Geheimnisse, erzwingen Formatierung, führen die richtigen Tests aus und schreiben kurze Commit-Zusammenfassungen für schnellere Reviews.
Die meisten Probleme in Reviews kommen nicht von „schwerem“ Code, sondern von vermeidbaren Fehlern, die in einen Commit rutschen: ein aktivierter Debug-Flag, eine unformatierte Datei, die laute Diffs erzeugt, ein vergessenes Update der Tests oder ein Geheimnis in einer Konfigurationsdatei. Einzelne Probleme sind klein, zusammen verwandeln sie eine saubere Review in einen langsamen Hin-und-Her-Prozess.
Commit-Zeit-Automatisierung ist der einfachste Ort, das zu stoppen. Wenn Checks direkt vor dem Erstellen eines Commits laufen, fangen sie Probleme ab, solange die Änderung noch frisch im Kopf ist. Einen Fehler zu beheben dauert Sekunden, weil du schon im Kontext arbeitest. Vergleiche das damit, den Fehler zwei Tage später in einem Pull Request zu finden, nachdem weitere Commits hinzugekommen sind und der Reviewer nachfragen muss, was passiert ist.
Git-Hooks sind praktisch, weil sie lokal laufen, ohne auf CI warten zu müssen. Sie sind aber kein Allheilmittel. Hooks können übersprungen, falsch konfiguriert oder auf verschiedenen Maschinen uneinheitlich sein, wenn das Team sie nicht standardisiert. Sie können auch nicht allein Qualität garantieren. Betrachte sie als Leitplanken, nicht als Tore.
Am meisten helfen Hooks, die "Review-Tax" zu verhindern, also wiederkehrendes, wenig wertvolles Feedback. Typische Beispiele sind potenziell sensitive Strings, die wie Tokens aussehen, Format- und Lint-Lärm, einfache „Hast du die richtigen Tests ausgeführt?“-Checks und kurze Kontextzusammenfassungen, die dem Reviewer die Absicht erklären.
Hier kommen Claude Code Git-Hooks gut ins Spiel: Sie übernehmen die langweilige Verifikationsarbeit und fügen genau in dem Moment, in dem du commitest, etwas menschenlesbaren Kontext hinzu.
Erwartungsmanagement ist wichtig. Halte lokale Hooks schnell und vorhersehbar, damit Leute sie nicht hassen. Schnelle Checks gehören auf den Laptop; langsame Checks später. Eine gute Aufteilung sind Sekunden bei Commit-Zeit und Minuten in CI. Wenn ein Hook regelmäßig so lange dauert, dass jemand auf „skip“ zurückgreift, hört er auf, das Repository zu schützen.
Ein einfaches Beispiel: Du änderst ein Modul und refaktorierst ein paar Funktionen. Ohne Automatisierung sieht ein Reviewer 400 verschobene Zeilen, keine Erwähnung von Tests und muss grundlegende Fragen stellen. Mit Commit-Zeit-Checks ist der Commit formatiert, eine relevante Testsuite wurde ausgeführt und die Commit-Message enthält eine kurze Zusammenfassung. Die Review startet dort, wo sie sollte: beim Design, nicht beim Aufräumen.
Git-Hooks sind gut für einfache Checks, aber meist enden sie bei Ja-/Nein-Regeln: „Ist die Datei formatiert?“ oder „Hast du den Linter ausgeführt?“. Claude Code kann eine leichte Bewertungsebene hinzufügen, indem es deinen gestagten Diff und ein paar zugehörige Dateien liest und dann Entscheidungen trifft, die eher dem entsprechen, wie Menschen Änderungen prüfen.
Mit Claude Code Git-Hooks kann der Hook anschauen, was du tatsächlich geändert hast, nicht nur, was im Repo existiert. So wird die Automatisierung selektiver. Sie kann sich auf berührte Module, geänderte Config-Dateien und neue Umgebungsvariablen fokussieren, statt jeden Commit wie einen Full-Build zu behandeln.
Praktische Aufgaben, bei denen „lies das Diff und denk drüber nach" sich auszahlt:
Constraints sind wichtig, weil ein langsamer Hook übersprungen wird. Halte das Ziel klein: Leitplanken hinzufügen, die häufige Fehler früh fangen, nicht ein zweites CI-System bei jedem Commit.
Eine gute Regel: Wenn es nicht in ein paar Sekunden fertig wird, gehört es wahrscheinlich in CI oder einen pre-push Hook. Viele Teams führen schnelle lokale Checks bei Commit-Zeit aus und lassen schwerere Tests später laufen.
Plane für Fehlerfälle. Wenn ein Modellaufruf timeoutet, entscheide, ob der Commit blockiert wird oder auf eine einfachere Prüfung zurückgefallen wird. Ein Fallback hält den Workflow vorhersehbar und verhindert, dass Leute lernen, Hooks zu deaktivieren.
Manche Setups rufen ein gehostetes Modell auf; andere laufen isolierter. Entscheide, welcher Code die Entwickler-Maschine verlassen darf (falls überhaupt), und begrenze, was gesendet wird. Der gestagte Diff plus eine kleine Menge referenzierter Dateien reicht oft aus.
Wenn du mit sensitiven Repositories arbeitest, sei explizit, wo die Analyse läuft und was geloggt wird. Ein konkretes Beispiel: Fügt ein Commit einen neuen Config-Wert wie STRIPE_SECRET=... hinzu, kann der Hook den Commit stoppen, erklären, was riskant aussieht, und vorschlagen, ihn in einen Secret-Manager oder eine lokale Env-Datei zu verschieben, bevor er das Remote-Repo erreicht.
Git-Hooks sind nur nützlich, wenn Leute sie anlassen und nicht das Commit fürchten. Der Trick ist, den richtigen Hook für die richtige Aufgabe zu wählen und alles Langsame aus dem heißen Pfad zu halten.
Eine einfache Karte, welche Checks normalerweise wohin gehören:
pre-commit: schnelle, lokale Checks, die offensichtliche Probleme blockieren (Formatierung, Secret-Scan, schneller Linter)commit-msg: Checks, die nur die Message brauchen (Ticket-ID, Länge, konventionelles Format)pre-push: schwerere Arbeit, die sich immer noch lohnt, bevor sie ins gemeinsame Repo gelangt (langsamere Tests, Typprüfungen, Build)Wenn du Claude Code Git-Hooks hinzufügst, behandle sie wie einen hilfreichen Reviewer, der sofort auftaucht, nicht wie einen Engpass. Alles, was Netzwerkaufrufe, vollständige Test-Suiten oder lange Analysen braucht, gehört in pre-push oder CI, nicht in pre-commit.
Eine praktische Entscheidungshilfe ist, Checks nach Geschwindigkeit und Wirkung zu sortieren. Erkennt es ein Hochrisiko-Problem (wie geleakte Schlüssel) und läuft in ein oder zwei Sekunden, gehört es in pre-commit. Dauert es 30–90 Sekunden, verschiebe es zu pre-push oder führe es nur bei bestimmten Dateitypen aus.
Teams brauchen auch eine klare Haltung zur Durchsetzung. Für ein Solo-Repo können Opt-in-Hooks in Ordnung sein. Für ein Team-Repo ist es üblich, die Grundlagen (Geheimnisse, Formatierung, Commit-Message-Regeln) durchzusetzen und schwerere Checks lokal beratend zu belassen, während CI das finale Tor bleibt.
Hook-Ausgaben sind wichtiger, als viele denken. Ein Hook, der fehlschlägt, sollte sagen, was passiert ist und was als Nächstes zu tun ist. Halte Meldungen kurz und konkret. Zeige möglichst Datei und Zeile, gib einen klaren Fix-Befehl, erkläre, wie man nur im echten Notfall umgeht (und wann nicht) und vermeide riesige Logs, außer der Nutzer bittet um „verbose".
Beispiel: Exportierst du ein Projekt aus Koder.ai und beginnst lokal zu committen, kann ein schneller pre-commit Hook sofort ein kopiertes API-Token finden, während pre-push die langsamere „nur Tests für geänderte Module"-Regel ausführt, bevor jemand den Branch sieht.
Ein Geheimnis ist alles, womit jemand in deinem Namen handeln oder private Systeme erreichen kann. Denke an API-Tokens, OAuth-Client-Secrets, Cloud-Keys, Datenbank-Passwörter, private Webhook-URLs, Signierschlüssel und sogar „temporäre" Test-Zugangsdaten. Ein versehentlicher Commit kann in einem Fork, einem CI-Log oder einem kopierten Diff landen und dann ist es nicht mehr temporär.
Der einfachste Gewinn ist, nur das zu scannen, was du gerade committest. Ein Hook sollte gestagte Änderungen (den Index) prüfen, nicht dein ganzes Repo. Das hält ihn schnell und vermeidet Lärm durch alte Dateien, die du nicht berührt hast. Es macht das Feedback auch fair: „dieser Commit enthält ein Problem" statt „dein Repo hatte einmal ein Problem".
Typische Dinge, die man früh kennzeichnen sollte: hochentropische Tokens (lange, zufällig aussehende Strings), bekannte Schlüssel-Formate (AWS-Keys, GitHub-Tokens, JWTs), Muster wie password=... oder api_key: ... in Configs, private URLs mit eingebetteten Credentials und .env-Dateien oder kopierte Produktionskonfigurationen.
False Positives kommen vor, besonders bei Testdaten, Hashes oder Beispiel-Dokumentation. Baue eine Allowlist ein, damit Leute weitermachen können, ohne den gesamten Check zu deaktivieren. Halte die Allowlist eng: exakte Pfade für Fixtures oder explizite Marker wie „dummy" oder „example", die dein Detector erkennt.
Wenn ein Geheimnis gefunden wird, sollte der Commit fehlschlagen und eine Nachricht anzeigen, die erklärt, was als Nächstes zu tun ist. Claude Code Git-Hooks können das freundlicher machen, indem sie eine kurze Erklärung basierend auf dem Diff erzeugen. Entscheidend sind jedoch klare, sichere nächste Schritte:
ERROR: Possible secret detected in staged file: config/app.yaml (line 12)
Reason: looks like an API token
Next steps:
1) Remove it from the change or move it to env vars
2) Rotate the token (assume it is compromised)
3) Re-stage and retry commit
If this is a false positive, add a narrow allowlist rule in .secrets-allowlist
Ein konkretes Beispiel: Jemand aktualisiert eine Backend-Config und fügt einen TEMP_API_KEY hinzu, damit eine Funktion in Dev läuft. Der Hook stoppt den Commit, empfiehlt, ihn in eine Umgebungsvariable zu verschieben, und erinnert daran, den Schlüssel zu rotieren, falls er real ist. Das ist eine kleine Unterbrechung, die eine große Aufräumarbeit später verhindert.
Formatierungsstreitigkeiten verschwenden Review-Zeit, aber langsame Hooks sind ein schneller Weg, sie deaktiviert zu bekommen. Der Sweet Spot sind einfache Regeln, ein Tool pro Sprache und nur das zu ändern, was gerade committet wird.
Wähle pro Sprache einen Formatter und mache ihn zur Autorität. Zwei Formatter, die unterschiedlich formatieren (oder ein Formatter plus ein Linter, der ebenfalls umschreibt), erzeugen laute Diffs und endlosen Churn. Halte es langweilig: ein JS/TS-Formatter, ein Go-Formatter, ein Dart-Formatter. Sorge außerdem dafür, dass alle dieselben Versionen ausführen, damit die Hook-Ausgabe auf verschiedenen Maschinen stabil ist.
Der größte Geschwindigkeitsgewinn ist, nur gestagte Dateien zu formatieren. Ein Repo bei jedem Commit komplett zu formatieren ist der Hauptgrund, warum Teams über pre-commit klagen. Ein staged-only Ansatz hält das Diff auch fokussiert auf das, was du geändert hast — genau das, was Reviewer wollen.
Praktische Entscheidungen, die Commits schnell halten:
Auto-Fix vs. Fail ist Team-Entscheidung; eine gemischte Strategie funktioniert gut. Auto-Fix ist super für mechanische Änderungen, weil es die "commit, fail, neu ausführen, wieder committen"-Schleife vermeidet. Fail kann besser sein, wenn du willst, dass Leute das Problem sehen und eine Richtung wählen. Wenn du fehlschlägst, drucke eine Anweisung, die jeder in 10 Sekunden ausführen kann.
Standardisiere Kleinigkeiten, die plattformübergreifenden Lärm verursachen. Zeilenenden und trailing whitespace sind häufige Übeltäter, besonders wenn Leute zwischen Windows, macOS und CI wechseln.
Eine einfache Policy, die selten Probleme macht:
Wo Claude Code Git-Hooks helfen kann, ist in der Verknüpfung: erkennen, welche gestagten Dateien welchen Formatter brauchen, sie in der richtigen Reihenfolge ausführen und Fehlschläge in verständlicher Sprache erklären. Zum Beispiel kann der Hook, wenn jemand eine Go- und eine TS-Datei staged, jede mit dem passenden Tool formatieren, die Ergebnisse re-stagen und dann eine kurze Notiz ausgeben wie „2 Dateien reformatiert, keine Verhaltensänderungen". Reviewer sehen sauberere Diffs und Entwickler fühlen sich nicht bestraft, häufig zu committen.
Eine einfache Regel macht Commits sicherer, ohne schmerzhaft zu sein: Führe nur die Tests aus, die zu dem passen, was du tatsächlich gestaged hast. Wenn der Hook den gestagten Diff (nicht deinen Working Tree) betrachtet, vermeidet er falsche Alarme von halb fertigen Dateien.
Beginne damit, zu erkennen, welche Bereiche berührt wurden. Die meisten Repos haben eine natürliche Struktur: Packages, Services, Apps oder Module. Ein Hook kann git diff --cached --name-only lesen und diese Pfade auf eine kleine Menge an Testbefehlen abbilden.
Ein paar Mapping-Regeln, die auch später verständlich bleiben:
web/ oder frontend/ -> npm test (oder das kleinstmögliche zielgerichtete Kommando)api/ oder server/ -> Backend-Unit-Tests (Integration standardmäßig überspringen)mobile/ -> schnelle Widget/Unit-Tests, nicht volle Device-Suitesdb/ oder migrations/ -> Migration-Linting plus kleine Schema-Checksshared/ -> Tests des Shared-Pakets, plus schnelle KonsumentenMit Claude Code Git-Hooks kannst du einen Schritt weitergehen: Claude schaut sich die gestagten Dateinamen an und schlägt eine minimale Testsuite vor, die der Hook dann ausführt. Halte die endgültige Entscheidungslogik aber regelbasiert, damit das Team vorhersagen kann, was passiert.
Teile die Arbeit zwischen Commit und Push auf. Commits sollten schnell bleiben, damit Leute Hooks nicht umgehen. Ein praktisches Muster ist:
Flaky und langsame Tests brauchen eine klare Policy, sonst wird dein Hook zum Lärm. Ein praktikabler Ansatz ist: Blocken bei klaren Fehlern (Formatierung, stabile Unit-Tests), Warnen bei bekannten flakigen Tests mit kurzer Meldung und langsame Suiten zu Push/CI verschieben. Wenn ein Test flaky ist, betrachte das als Bug: verfolge ihn, behebe ihn und entferne den Warnmodus, sobald er wieder stabil ist.
Ein gutes Diff ist nicht immer leicht zu prüfen. Eine kurze Commit-Zusammenfassung kann eine 10-minütige Lektüre in einen 2-minütigen Check verwandeln, besonders wenn Änderungen mehrere Dateien betreffen oder Refactorings enthalten.
Die Idee ist einfach: Wenn du git commit ausführst, fragt dein Hook Claude Code, den gestagten Diff zu lesen und eine 3–6-zeilige Notiz zu erstellen, die die Fragen beantwortet, die Reviewer immer haben: was hat sich geändert, warum, wie riskant ist es und wie wurde es getestet.
Halte die Ausgabe knapp und konsistent, damit Reviewer ihr vertrauen:
Du kannst das direkt in die Commit-Message einfügen (z. B. als kurzen Footer) oder in einer Datei speichern, die dein Team in die PR-Beschreibung kopiert. Die Commit-Message funktioniert gut, wenn du willst, dass der Kontext mit der Änderung reist. Eine separate Datei ist besser, wenn dein Team saubere, konventionelle Commit-Subjects bevorzugt.
Ein Zusammenfassungstool sollte strenger sein als ein Reviewer. Bevor du Diff-Inhalt an ein Modell schickst, filtere Zeilen, die wie API-Keys, private Keys, Tokens, .env-Werte oder Credentials aussehen. Filtere auch gängige Header und Cookies, wenn dein Repo aufgezeichneten HTTP-Traffic enthält. Wenn der Hook sensible Muster erkennt, kann er die Zeilen redigieren oder auf eine generische Zusammenfassung wie "credentials-related changes redacted" zurückfallen.
Beispiel: Du aktualisierst einen Billing-Endpoint und berührst drei Dateien. Der gestagte Diff ist wegen Renames laut, aber die Zusammenfassung sagt: „Fügt Idempotency-Key-Handling für Charge-Erstellung hinzu, um doppelte Abrechnungen zu verhindern. Grund: Retries führten zu doppelten Buchungen. Risiko: medium (Payment-Pfad). Tests: Unit-Tests für den Billing-Service, manuelle Anfrage-Wiederholung." Genau das, was ein Reviewer braucht, ohne zuerst jede Zeile zu lesen.
Du behebst einen kleinen Bug und passt gleichzeitig eine Config an. Der Bug ist eine Ein-Zeilen-Änderung in billing/tax.go. Die Config-Änderung aktualisiert config/staging.yaml, um auf einen neuen Endpoint zu verweisen.
Du führst git commit -am "Fix tax rounding" aus. Deine Claude Code Git-Hooks springen an und führen eine schnelle Reihe von Checks in vorhersagbarer Reihenfolge aus.
Zuerst schaut der Secret-Scan nur auf das, was sich geändert hat, nicht auf dein ganzes Repo. Er markiert, dass die Staging-Config etwas enthält, das wie ein echter API-Key aussieht.
ERROR: Possible secret detected in config/staging.yaml:12
Pattern: api_key=sk_live_...
Fix: remove the key and use an env var reference (e.g., API_KEY)
Override: set ALLOW_SECRETS=1 (not recommended)
Du ersetzt den Wert durch eine Umgebungsvariablen-Referenz und commitest erneut.
Als Nächstes läuft die Formatierung nur dort, wo es wichtig ist. Wenn deine Go-Datei nicht formatiert ist, schlägt der Hook mit einem kurzen Hinweis fehl wie „run gofmt on billing/tax.go“. Du führst den Formatter aus und der Hook besteht in Sekunden.
Dann läuft das Test-Gate gezielt. Weil du billing/ berührt hast, werden nur die Billing-Unit-Tests ausgeführt (nicht die komplette Suite). Wenn ein Test fehlschlägt, zeigt der Hook den exakten Befehl zum lokalen Reproduzieren. Du behebst den Rounding-Edgecase und führst die gleichen Tests erneut aus.
Schließlich erzeugt der Hook aus dem Diff eine Reviewer-Zusammenfassung. Sie ist kurz und spezifisch, z. B.:
Was der Reviewer sieht, ist ein Commit, der bereits sauber ist: keine geleakten Geheimnisse, konsistente Formatierung und Tests, die zur Änderung passen. Er bekommt außerdem eine fertige Zusammenfassung, sodass er sich auf die Logik konzentrieren kann, statt die Absicht zu suchen.
Der schnellste Weg, Hooks nutzlos zu machen, ist, sie schmerzhaft zu machen. Wenn ein Hook so lange dauert, dass er den Flow einer Person unterbricht, umgehen Leute ihn mit --no-verify oder löschen ihn. Halte alles Schwere aus pre-commit und führe es in CI oder on-demand aus.
Eine praktische Regel: pre-commit sollte sich wie eine Rechtschreibprüfung anfühlen, nicht wie eine Testsuite. Wenn du cleverere Checks mit Claude Code willst, nutze sie, um zu entscheiden, was ausgeführt wird, nicht um alles auszuführen.
Mache Hooks standardmäßig schnell und streng nur, wenn nötig. Zum Beispiel: schnelle Formatierung + Secret-Scan bei jedem Commit, Tests nur für betroffene Module.
Ein einfaches Zeitbudget:
pre-commit: 1 bis 5 Sekunden insgesamtcommit-msg: unter 1 Sekundepre-push oder in CI verschiebenAI ist super für Vorschläge, nicht für Policy. Wenn du ein Modell einfach „review the diff" fragst, bekommst du unterschiedliche Ergebnisse. Definiere, was der Hook tun muss (und was er niemals tun darf). Zum Beispiel: Er darf eine Reviewer-Zusammenfassung generieren, aber keinen Code umschreiben, außer ein Formatter hat bereits deterministische Änderungen vorgenommen.
Viele Hooks scannen versehentlich den Working Tree und brechen den Commit wegen ungestagter Änderungen ab. Das fühlt sich unfair an.
Vermeide das, indem du immer gestagte Inhalte als Input verwendest. Ein guter Test: Ändere eine Datei, stage nur die Hälfte und prüfe, ob der Hook nur das Gemeldete anzeigt.
Wenn jeder Commit eine Warnung auslöst, werden Warnungen zum Rauschen. Feine Muster, enge Allowlists für bekannte sichere Strings und downgrade von „vielleicht"-Treffern zu Warnungen mit klarem Fix helfen.
Konkretes Beispiel: Wenn dein Secret-Scanner Test-Keys in fixtures/ markiert, füge eine Regel hinzu, diesen Ordner zu ignorieren, blockiere aber echte Keys in App-Config-Dateien.
Wenn du Claude Code Git-Hooks nutzen willst, ohne das Team zu nerven, ist das Ziel einfach: Reale Probleme früh fangen, still sein, wenn alles normal ist, und die Commit-Schleife schnell halten.
Eine praktische Checkliste fürs meiste Repos:
Ein kleines Detail mit großer Wirkung: Lass die Reviewer-Zusammenfassung jedes Mal gleich aussehen. Eine einfache Vorlage reicht und trainiert Reviewer, schnell zu scannen.
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
Nächste Schritte, die die Einführung erleichtern:
Wenn du gerne Werkzeug in einer Chat-first-Weise baust, kann Koder.ai (koder.ai) praktisch sein, um kleine Helfer-Skripte rund um deine Hooks zu generieren und sicher mit Snapshots und Rollback zu iterieren, bevor du den Quellcode in dein Repo exportierst.
Fange mit den Wiederholungstätern an, die Review-Zeit verschwenden:
Alles, was langsam ist (voller Testlauf, tiefe statische Analyse), gehört zu pre-push oder CI.
Eine gute Standardaufteilung ist:
pre-commit für schnelle Checks, die gestagte Änderungen betrachten (Geheimnisse, Formatierung, schnelles Linting, selektive Unit-Tests)commit-msg für Commit-Message-Regeln (Länge, Format, Ticket-ID)pre-push für langsamere, aber noch lokale Checks (breitere Tests, Builds)Wenn ein Check regelmäßig mehr als ein paar Sekunden braucht, verschiebe ihn nach hinten.
Behandle Commit-Time-Hooks als Schutzschienen, nicht als einzige Durchsetzung.
Eine praktische Policy: Hooks helfen Entwicklern; CI schützt den main-Branch.
Scanne den gestagten Diff (den Index), nicht das ganze Repo.
Wenn du einen Full-Repo-Scan brauchst, führe ihn zeitgesteuert oder in CI aus.
Blockiere bei hochvertraulichen Treffern (echte Schlüssel-Formate, private Key-Blöcke, offensichtliche password=-Werte in Configs). Warne, wenn es unklar ist.
Füge eine enge Allowlist für bekannte, sichere Fälle hinzu, z. B.:
DUMMY_KEY)Wenn Leute ständig falsche Alarme sehen, deaktivieren sie den Hook.
Formatiere nur gestagte Dateien und nutze pro Sprache genau einen Formatter.
Praktische Defaults:
So bleiben Diffs sauber, ohne jeden Commit in eine lange Überarbeitung zu verwandeln.
Mappe betroffene Pfade auf eine kleine Menge schneller Testbefehle.
Beispiel-Ansatz:
git diff --cached --name-onlypre-push oder CI lassenSo bleiben Commits schnell und die häufigsten Fehler werden früh gefangen.
Kurz und konsistent (3–6 Zeilen). Eine einfache Vorlage:
Du kannst es an die Commit-Message anhängen oder als Textausgabe für die PR-Beschreibung speichern.
Vor dem Senden an ein Modell redigieren und konservativ sein.
.env-Werte, private Keys, Cookies oder Auth-Header aussehenTeile lieber weniger, besonders in privaten Repositories.
Mach Hooks vorhersehbar und schnell:
pre-commit)Wenn der Hook langsam oder unzuverlässig wirkt, nutzen Entwickler --no-verify.