Pre-Commit-Hooks: die Schranke gegen schlechte Inhalte

Würdigung — die Schranke vor dem ersten Schaden#

Klassisch ist die Qualitätssicherung an Websites ein End-zu-Ende-Vorgang: Inhalt schreiben, einbauen, lokal anschauen, vielleicht ein Review, dann veröffentlichen. Das ist in Ordnung, solange alle beteiligten Personen aufmerksam und unbelastet sind — was in der Praxis fast nie der Fall ist. Müdigkeit, Zeitdruck, parallele Aufgaben, KI-Assistenz mit Eigendynamik — all das produziert kleine Fehler, die niemand mehr fängt.

Pre-Commit-Hooks setzen einen Schritt vorher an: bevor eine Änderung überhaupt in die Historie wandert, läuft eine kurze Reihe von Prüfungen. Wenn eine Prüfung scheitert, kommt der Commit gar nicht erst zustande. Es ist die Schranke vor dem ersten Schaden — und sie wirkt zuverlässig, weil sie nicht auf Aufmerksamkeit angewiesen ist, sondern auf Konfiguration.

Was Pre-Commit-Hooks sind#

Git kennt seit jeher das Konzept der Hooks: Skripte, die zu bestimmten Zeitpunkten im Versionierungs-Workflow automatisch ausgeführt werden — bei einem Commit, beim Push, beim Merge. Der pre-commit-Hook läuft genau einmal pro Commit, direkt nachdem man den Commit ausgelöst hat und bevor er angelegt wird. Wenn das Skript mit einem Fehler-Status endet, wird der Commit verworfen.

Das ist mächtig — und unhandlich, wenn man es händisch verwalten muss (Hooks leben im .git/hooks/-Verzeichnis, das nicht zur Versionskontrolle gehört). Die heute übliche Lösung heißt Husky: ein kleines Werkzeug, das den .husky/-Ordner als versionierten Ort etabliert. Im .husky/pre-commit-Skript steht, was beim Commit laufen soll — und weil der Ordner mit dem Repo wandert, hat jede Person, die das Repo klont, sofort dieselben Schranken.

Die drei Linter im fahoch2.de-Repo#

Im Pre-Commit-Hook des fahoch2.de-Repos laufen drei Prüfungen verkettet:

1. Voice-Linter (scripts/lint-voice.mjs)#

Eigenes Skript, das die Voice-Doktrin aus unserem Briefing 04 prüft. Konkret fängt es:

• Marketing-Phrasen, die wir bei FA² bewusst vermeiden („Wir sind Ihre Profis für …", „Vertrauen ist alles", „Mehr als nur eine Website" — die ganze Liste der Anti-Floskeln ist im Linter codiert).
• KI-Slop-Marker: typische Formulierungen, die KI-Assistenten gern produzieren („In der heutigen schnelllebigen Welt", „Es ist wichtig zu beachten", inflationäre Doppelpunkte am Satzanfang).
• Inline-Platzhalter, die als Reste eines Konzept-Stadiums übrig bleiben (Marker im Stil „große Überschrift Punkt drei" im Fließtext — der Linter erzwingt, dass solche Stellen vor dem Commit aufgelöst sind).
• Cluster-Coverage: für die Insights-Pipeline prüft der Linter, dass jeder neue Insight-Slug in src/data/insights.ts auch ein Mapping in src/data/insight-clusters.ts hat. Ohne Mapping erscheint der Artikel weder im Filter noch in einer Rubrik — ein Fehler, der vor diesem Lint zweimal passiert ist.

2. ESLint inklusive jsx-a11y#

ESLint ist der etablierte Code-Standard-Linter für JavaScript/TypeScriptTypeScript · zum GlossarJavaScript mit statischer Typprüfung — fängt Tippfehler und Datenform-Bruch beim Build statt im Produktivbetrieb.. Wir reichen ihn mit dem jsx-a11y-Plugin an, das Barrierefreiheits-Fehler in React-Komponenten fängt — z. B. ein <img>-Tag ohne alt-Attribut, ein <button> ohne erkennbaren Text, ein Eingabefeld ohne zugeordnetes Label. Das ist nicht nur Qualitäts-Hygiene, sondern hat für Kanzlei-Websites mit dem BFSG auch eine rechtliche Komponente: barrierefrei-Mindeststandards werden so beim Commit erzwungen statt im finalen Review erhofft.

3. DSE-Konsistenz-Linter (scripts/lint-dse-consistency.mjs)#

Eigener Linter, der prüft, ob die Sektion-Nummern und Sub-Auftragsverarbeiter unserer Datenschutzerklärung im Code konsistent verwendet sind. Beispiel: Wenn unsere DSEDSE · zum GlossarDatenschutzerklärung — die Pflicht-Information für Website-Besucher nach Art. 13 DSGVO. eine Sektion „6.3 CloudflareCloudflare · zum GlossarUS-Anbieter für CDN, WAF, DDoS-Schutz und Turnstile — Privacy-by-Design-Ausrichtung." hat und im Code an anderer Stelle auf „§ 6.3 unserer Datenschutzerklärung" verwiesen wird, prüft der Linter, dass die Nummer existiert und der Anbieter wirklich erwähnt ist. Verhindert genau die Soll-Ist-Drift, die wir in Kanzlei-Audits regelmäßig sehen.

Wie das im Repo aussieht#

Die Verkettung in .husky/pre-commit ist erfreulich kurz — der Hook sammelt die gestageten Dateien nach Typ, ruft die passenden Linter mit genau diesen Dateien auf, und scheitert beim ersten Fehler. So bleibt der Hook schnell (weniger als zwei Sekunden in der Regel) und liefert beim Scheitern die konkrete Fehler-Meldung mit Datei und Zeile — keine Suche, was schiefging.

Praktischer Nebeneffekt: Wenn der Hook scheitert, sieht man im Terminal sofort, welche Regel verletzt ist. „Marketing-Phrase ‚wir sind Ihre Profis' in src/data/insights.ts:1234" ist eine konkrete Reparatur-Anweisung, nicht ein vager Review-Kommentar Tage später.

Was Kanzlei-Websites davon haben#

Drei Effekte, die sich erst nach einigen Monaten zeigen — und dann sehr deutlich:

• Rechtliche Konsistenz mechanisch sichern. Eine Datenschutzerklärung, die im Code an drei Stellen erwähnt wird, gerät leicht aus dem Takt — ein Linter, der das beim Commit prüft, schließt diese Lücke strukturell. Wertvoller, je länger die Site lebt und je mehr Personen daran arbeiten.
• Voice bleibt scharf, ohne dauerhaftes Lektorat. Bei einer Site mit viel Content (Insights, Stadt-Landingpages, Audit-Reports) ist ein konsistenter Ton schwierig. Ein Voice-Linter, der die häufigsten Slop-Marker und Anti-Phrasen fängt, hält die Mindest-Linie auch dann, wenn Texte unter Zeitdruck entstehen oder KI-gestützt erzeugt werden.
• Onboarding neuer Mitspieler ist eingebaut. Ein neuer Entwickler, ein neuer KI-Assistent, eine Übergabe — alle bekommen die Qualitäts-Schranken automatisch mitgeliefert, weil sie im Repo leben. Niemand muss eine PDF mit „so schreiben wir" lesen — der Linter sagt es im Moment des Verstoßes.

Wo die Grenze liegt#

Pre-Commit-Hooks sind keine Endprüfung. Sie fangen syntaktisch-strukturelle Mängel und konsistente Verstöße gegen explizite Regeln — nicht inhaltliche Fehler, nicht stilistische Feinheiten, nicht semantische Sinnlosigkeit. Ein Satz kann grammatikalisch tadellos und Voice-konform sein und trotzdem falsch behaupten. Genau dafür gibt es danach das menschliche Review, den fa2-lektor-Skill und gegebenenfalls die rechtliche Prüfung durch den Fachanwalt.

Außerdem: Hooks gelten lokal. Wer mit dem Flag --no-verify committen will, kann sie umgehen — in unserem Briefing 04 ist das ausdrücklich nur für Notfälle vorgesehen und sollte im Commit-Text begründet werden. Für das verbindliche Sicherheitsnetz gehören die wichtigsten Prüfungen zusätzlich in die CI-Pipeline.

Wie wir es bauen#

Bei jedem neuen Kanzlei-Projekt richten wir Husky ein, sobald die Grund-Struktur steht — Voice-Linter, ESLintESLint · zum GlossarStatischer Code-Analyzer für JavaScript/TypeScript — fängt Style-Brüche und Anti-Patterns. inkl. jsx-a11y, und projektspezifische Linter (z. B. ein DSE-Konsistenz-Linter, sobald die Datenschutzerklärung mehr als trivial ist). Das ist eine Stunde Arbeit am Anfang und spart über das Projekt-Leben gerechnet viele Stunden Reibung. Die Linter wachsen mit: jedes Mal, wenn ein bestimmter Fehler-Typ zweimal auftaucht, wird die Prüfung in die Hook-Kette aufgenommen — so härtet sich die Site strukturell aus.

Für eine strukturierte Bewertung der bestehenden Qualitäts-Schranken einer Kanzlei-Site empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Pre-Commit-Hooks sind kleine Prüfprogramme, die vor jedem Commit automatisch laufen und einen Commit ablehnen, der definierte Mindeststandards verletzt. Sie wirken zuverlässig, weil sie nicht auf Aufmerksamkeit angewiesen sind. Im fahoch2.de-Repo verketten wir drei Schranken: einen eigenen Voice-Linter (Marketing-Phrasen, KI-Slop, Inline-Platzhalter, Cluster-Coverage), ESLint inklusive jsx-a11y für Barrierefreiheit, und einen DSE-Konsistenz-Linter, der die Datenschutzerklärung gegen Code-Verweise prüft. Für Kanzlei-Websites entsteht so ein strukturelles Sicherheitsnetz, das rechtliche Konsistenz, Voice und Barrierefreiheit mechanisch sichert und Onboarding neuer Mitspieler vereinfacht. Hooks ersetzen keine inhaltliche Endprüfung — sie fangen vorhersagbare Fehler, damit die Endprüfung sich auf das Inhaltliche konzentrieren kann.

Quellen#

• Husky — Modern native Git hooks — abgerufen 2026-06-05
• Git — Customizing Git Hooks — abgerufen 2026-06-05
• ESLint — Official Documentation — abgerufen 2026-06-05
• eslint-plugin-jsx-a11y — Repository — abgerufen 2026-06-05

Disclaimer: Beschreibung des tatsächlichen Setup von fahoch2.de zum Zeitpunkt der Veröffentlichung. Konkrete Linter-Auswahl variiert nach Stack und Anforderung; das Prinzip der lokalen Qualitäts-Schranke bleibt gleich.