git-guardrails-claude-code

Überblick über die git-guardrails-claude-code-Skill

Die Skill git-guardrails-claude-code sorgt dafür, dass Claude Code eine kurze Liste destruktiver Git-Befehle ablehnt, bevor sie ausgeführt werden. Ihr eigentlicher Zweck ist einfach: eine zusätzliche Sicherheitsschicht einzuziehen, damit eine AI-Coding-Session nicht nebenbei git push, git reset --hard, git clean -f, das Löschen von Branches mit git branch -D oder das Verwerfen von Änderungen im Working Tree mit git checkout . oder git restore . ausführt.

Für wen sich git-guardrails-claude-code eignet

Diese Skill passt besonders gut für Nutzerinnen und Nutzer, die:

• Claude Code direkt auf echten Repositories einsetzen
• AI-Unterstützung möchten, aber keine irreversiblen Git-Aktionen durch die AI zulassen wollen
• in geteilten Repos, produktiven Repos oder Kunden-Codebasen arbeiten
• lokale Durchsetzung einer Richtlinie gegenüber bloßen „bitte vorsichtig sein“-Prompts bevorzugen

Wenn dein Hauptproblem versehentliche Code-Zerstörung oder unerlaubte Pushes während einer Agent-Session ist, ist git-guardrails-claude-code eine starke Wahl.

Was daran anders ist als bei einem normalen Prompt

Ein normaler Prompt kann Claude zwar anweisen, riskante Befehle nicht auszuführen, aber Prompts sind nur weiche Leitplanken. git-guardrails-claude-code nutzt einen PreToolUse-Hook, sodass die Einschränkung im Ausführungspfad von Claude Code verankert ist und nicht nur im Gesprächskontext. Genau das ist der entscheidende Unterschied — und der Hauptgrund für die Installation.

Was tatsächlich blockiert wird

Das mitgelieferte Shell-Script prüft eingehende Bash-Befehle und blockiert unter anderem folgende Muster:

• git push
• git reset --hard
• git clean -f
• git clean -fd
• git branch -D
• git checkout .
• git restore .
• Force-Push-nahe Treffer wie push --force

Die Block-Meldung teilt Claude mit, dass es nicht befugt ist, diesen Befehl zu verwenden.

Was diese Skill nicht leistet

git-guardrails-claude-code ist keine vollständige Git-Policy-Engine. Sie:

• bewertet nicht die Qualität von Commits
• erzwingt keine Freigaben
• unterscheidet nicht zwischen sicheren und unsicheren Push-Zielen
• kennt keine repo-spezifischen Branching-Regeln
• schützt keine Befehle außerhalb der aufgeführten Muster, sofern du das Script nicht anpasst

Für die Einordnung bei der Einführung ist das wichtig: Das hier ist eine gezielte Guardrail, keine umfassende Governance-Lösung.

So verwendest du die git-guardrails-claude-code-Skill

Triff zuerst die Scope-Entscheidung

Die erste praktische Entscheidung in der Upstream-Skill ist, ob du die Guardrail installierst:

• nur für dieses Projekt in .claude/settings.json, oder
• für alle Projekte in ~/.claude/settings.json

Diese Entscheidung bestimmt, wohin du das Script kopierst und wie breit die Sperre greift. Für die meisten Teams ist eine projektbezogene Installation zum Testen sicherer. Eine globale Installation ergibt Sinn, wenn du dieselben Git-Einschränkungen überall durchsetzen willst.

Lies zuerst diese Dateien

Fast alles Wichtige erschließt sich dir beim Lesen von:

1. SKILL.md
2. scripts/block-dangerous-git.sh

Diese Reihenfolge ist sinnvoll, weil SKILL.md erklärt, wie der Hook verdrahtet wird, während scripts/block-dangerous-git.sh die exakt blockierten Befehlsmuster zeigt. Wenn dir False Positives oder Lücken wichtig sind, ist das Script aussagekräftiger als die Beschreibung.

Installationskontext für git-guardrails-claude-code

Der git-guardrails-claude-code install-Prozess ist überwiegend manuelle Einrichtung im Hook-System von Claude Code:

1. das Shell-Script in ein Hooks-Verzeichnis kopieren
2. ausführbar machen
3. unter PreToolUse für den Bash-Matcher registrieren

Der Repository-Pfad des Quell-Scripts lautet:

scripts/block-dangerous-git.sh

Zielpfade sind:

• Projekt-Scope: .claude/hooks/block-dangerous-git.sh
• Globaler Scope: ~/.claude/hooks/block-dangerous-git.sh

Dann ausführbar machen:

chmod +x .claude/hooks/block-dangerous-git.sh

oder für den globalen Scope:

chmod +x ~/.claude/hooks/block-dangerous-git.sh

Den Claude-Code-Hook korrekt eintragen

Für den Projekt-Scope zeigt die Skill einen PreToolUse-Hook in .claude/settings.json, der das kopierte Script mit "$CLAUDE_PROJECT_DIR" ausführt.

Die entscheidenden Verdrahtungspunkte sind:

• Hook-Event: PreToolUse
• Matcher: Bash
• Hook-Typ: command
• Command: Pfad zu block-dangerous-git.sh

Wenn dieser Hook nicht unter PreToolUse registriert ist, existiert das Script zwar, fängt aber nie Befehle ab.

Wie das Script in der Praxis arbeitet

Das Shell-Script liest den Tool-Input aus der Standard-Eingabe, extrahiert .tool_input.command mit jq und prüft den Befehl mit grep -qE gegen ein kleines Array gefährlicher Muster.

Das bedeutet: typische Hürden bei der Einführung sind sehr konkret:

• jq muss in der Umgebung verfügbar sein
• der Command-Pfad in den Settings muss stimmen
• das Script muss ausführbar sein
• Claude Code muss Bash-Tool-Aufrufe tatsächlich über das Hook-System schicken

Wenn eines dieser Teile nicht funktioniert, ist der Schutz in der Praxis stillschweigend schwächer, als du denkst.

Welche Eingaben die Skill von dir braucht

Die Upstream-Skill selbst benötigt nur wenig Kontext, aber ein sinnvoller git-guardrails-claude-code usage-Ablauf beginnt mit diesen Entscheidungen:

• nur projektbezogen oder global
• ob die standardmäßig blockierte Liste ausreicht
• ob dein Team zusätzlich Befehle wie git tag -d, git rebase --abort oder remote-spezifische Pushes blockieren will
• ob Nutzerinnen und Nutzer weiterhin einen dokumentierten manuellen Eskalationsweg für legitime Pushes brauchen

Ohne diese Antworten ist die Installation zwar einfach, aber der Policy-Fit kann schlecht ausfallen.

Aus einem groben Ziel einen guten Prompt machen

Schwacher Prompt:

• „Set up git guardrails.“

Stärkerer Prompt:

• „Install git-guardrails-claude-code for this project only. Copy the hook script into .claude/hooks/, make it executable, update .claude/settings.json with a PreToolUse hook for Bash, and then show me the exact blocked Git patterns from the script.”

Warum das besser ist:

• der Scope ist klar definiert
• das Zielverzeichnis ist vorgegeben
• sowohl Einrichtung als auch Verifikation werden angefordert
• die Wahrscheinlichkeit sinkt, dass Claude eine andere Hook-Struktur improvisiert

Ein guter First-Run-Workflow

Ein praxistauglicher git-guardrails-claude-code guide sieht so aus:

1. Projekt- oder Global-Scope festlegen
2. scripts/block-dangerous-git.sh prüfen
3. das Script in das Ziel-Hooks-Verzeichnis kopieren
4. chmod +x auf die kopierte Datei anwenden
5. den PreToolUse-Hook in der richtigen Settings-Datei verdrahten
6. mit einer harmlosen Simulation oder einem eindeutig blockierten Befehl in einem sicheren Repo testen
7. entscheiden, ob die Muster angepasst werden sollen

Diese Reihenfolge ist wichtig, weil du so die tatsächliche Enforcement-Liste prüfst, bevor du die Lösung breiter ausrollst.

So validierst du die Installation

Höre nicht bei „die Datei ist vorhanden“ auf. Prüfe das Verhalten:

• bestätigen, dass Claude Code wirklich die richtige Settings-Datei verwendet
• prüfen, dass der Hook-Command auf das kopierte Script zeigt und nicht auf den Quellpfad im Repository
• ein blockiertes Muster in einem Wegwerf-Repo auslösen
• kontrollieren, dass Claude eine Ablehnung erhält, statt den Befehl auszuführen

Bei dieser Skill ist Verifikation des tatsächlichen Verhaltens wichtiger als eine reine Sichtprüfung.

Best Fit für Git-Workflows

git-guardrails-claude-code for Git Workflows ist besonders nützlich, wenn dein bevorzugter AI-Workflow so aussieht:

• Claude darf Dateien frei bearbeiten
• Claude darf Diffs und Status prüfen
• Branch-Löschung, Force Push, Hard Reset und Cleanup-Befehle bleiben unter expliziter menschlicher Kontrolle

Diese Trennung funktioniert gut, weil sie AI-Produktivität bei Coding-Aufgaben erhält und irreversible Repository-Aktionen manuell hält.

Wann du das Script anpassen solltest

Die Standardliste ist bewusst eng gehalten. Passe scripts/block-dangerous-git.sh an, wenn:

• dein Team git push grundsätzlich erlaubt, aber nur --force blockieren möchte
• du zusätzlich git commit --amend sperren willst
• dein Workflow sensible Muster für das Löschen von Branches enthält
• du je Repository unterschiedliche Regeln brauchst

Der zentrale Trade-off ist Einfachheit versus Präzision. Das Standardscript lässt sich leicht auditieren; ein stark angepasstes Script braucht deutlich mehr Tests.

FAQ zur git-guardrails-claude-code-Skill

Ist git-guardrails-claude-code gut für Einsteiger

Ja — sofern die Person bereits Claude Code nutzt und einen sichereren Standardrahmen für Git möchte. Das Setup ist kurz, und das Konzept ist leicht nachvollziehbar: Bash-Tool-Aufrufe vor der Ausführung abfangen. Nur die JSON-Hook-Konfiguration und Shell-Script-Berechtigungen sind leicht technisch.

Ist das besser, als Claude einfach zu sagen „never push“

Ja, für die Befehle, die tatsächlich abgedeckt sind. git-guardrails-claude-code macht aus einer Gesprächsregel eine Prüfung zur Ausführungszeit. Das ist deutlich verlässlicher, als sich allein auf Prompt-Gedächtnis zu verlassen.

Blockiert git-guardrails-claude-code alle gefährlichen Git-Befehle

Nein. Blockiert werden die expliziten Muster im Script. Wenn dein Risikomodell weitere Befehle umfasst, musst du sie selbst ergänzen. Das ist eine zentrale Grenze dieser Skill.

Kann ich git-guardrails-claude-code global verwenden

Ja. Die Skill unterstützt ausdrücklich eine globale Installation über ~/.claude/settings.json und ~/.claude/hooks/block-dangerous-git.sh. Global ist bequem, aber projektbezogen lässt sich leichter testen und ist sicherer, wenn verschiedene Repositories unterschiedliche Regeln brauchen.

Stört das die normale Entwicklungsarbeit

Meistens kaum — vorausgesetzt, dein normaler Workflow erwartet nicht, dass Claude pusht oder destruktive Git-Cleanup-Schritte übernimmt. Am besten passt die Skill zu einem Ablauf, in dem Claude Code bearbeitet, Tests ausführt und Änderungen vorbereitet, während ein Mensch die finale Git-Autorität behält.

Wann sollte ich diese Skill nicht verwenden

Lass git-guardrails-claude-code aus, wenn:

• du tatsächlich möchtest, dass Claude Git End-to-End steuert
• dein Team differenzierte Allowlists statt einfacher Pattern-Blocks braucht
• du dich nicht auf Shell-Hooks oder jq verlassen kannst
• du eine organisationsweite Durchsetzung jenseits lokaler Claude-Code-Konfiguration benötigst

In solchen Fällen wirkt die Skill schnell zu eng gefasst oder zu lokal.

So verbesserst du die git-guardrails-claude-code-Skill

Die blockierten Muster an deinen realen Risiken ausrichten

Der schnellste Weg, git-guardrails-claude-code zu verbessern, ist der Abgleich der Standard-Musterliste mit den Git-Fehlern, die für euch tatsächlich relevant sind. Viele Teams sorgen sich weniger um alle Pushes, sondern eher um:

• Force Pushes
• Branch-Löschungen auf geschützten Branches
• destruktive Cleanup-Befehle in Monorepos
• Working-Tree-Resets während des Debuggings

Wenn eure Policy anders aussieht, bearbeite das Pattern-Array, statt die Standardeinstellung blind zu übernehmen.

Claude präzisere Installationsanweisungen geben

Wenn du Claude bittest, diese Skill einzurichten, gib konkrete Details mit:

• Scope
• exakter Zielpfad
• ob bestehende Hooks erhalten oder zusammengeführt werden sollen
• ob die finale JSON-Datei zur Prüfung ausgegeben werden soll
• ob der Hook nach der Einrichtung getestet werden soll

Ein stärkerer Auftrag wäre:

• „Install git-guardrails-claude-code only in this repo, merge with any existing .claude/settings.json hooks instead of overwriting them, and show the final settings diff.”

So vermeidest du einen der häufigsten Fehler: bestehende Hook-Konfiguration zu überschreiben.

Auf Fehler beim Hook-Merge achten

Ein realistisches Problem ist oft nicht das Shell-Script, sondern das Update der Settings-Datei. Wenn ein Repository bereits hooks konfiguriert hat, kann eine unvorsichtige Installation sie überschreiben. Fordere deshalb:

• einen Diff statt eines blinden Rewrite
• Erhalt bestehender PreToolUse-Einträge
• eine Erklärung der Hook-Reihenfolge, falls mehrere Commands laufen

Für viele Nutzer ist das wichtiger als die Liste blockierter Befehle.

False Positives und Umgehungen testen

Weil das Script mit Pattern-Matching arbeitet, solltest du Folgendes testen:

• legitime Befehle, die durchgehen sollen
• blockierte Befehle, die scheitern sollen
• Varianten, von denen du annimmst, dass sie blockiert sind, es aber womöglich nicht sind
• Command-Strings, die ähnliche Texte auf unerwartete Weise enthalten

Genau hier stärkst du das Vertrauen in git-guardrails-claude-code usage, besonders vor einem globalen Rollout.

Das Script erst nach realen Fehlstellen strenger machen

Es ist verlockend, sofort viele Muster hinzuzufügen. Widerstehe dem, solange du keine belastbaren Hinweise hast. Eine kurze, gut lesbare Blocklist ist leichter zu verstehen, ihr eher zu vertrauen und einfacher zu pflegen. Erweitere sie erst, wenn du beobachtet hast:

• welche Befehle Claude häufig versucht
• welche Befehle Nutzer als riskant ansehen
• welche Muster durchgerutscht sind
• welche Befehle blockiert wurden, aber nicht hätten blockiert werden sollen

So bleibt die Guardrail nachvollziehbar.

Einen menschlichen Eskalationspfad ergänzen

Eine sinnvolle operative Verbesserung ist, die Guardrail mit einer klaren Regel zu kombinieren, zum Beispiel:

• Claude darf Commits vorbereiten und Push-Schritte erklären
• ein Mensch führt den finalen Push oder destruktive Cleanup-Schritte manuell aus

Das verbessert die Skill, weil Nutzer dann nicht mehr gegen die Guardrail anarbeiten, sondern ihren Workflow darum herum gestalten.

Erneut prüfen, ob globaler oder projektbezogener Scope noch passt

Nach der ersten Nutzungsphase solltest du den Scope neu bewerten:

• wenn die Regel in allen Repos funktioniert, stelle auf global um
• wenn manche Repos lockereres Git-Verhalten brauchen, bleibe projektlokal
• wenn Teams unterschiedlich arbeiten, pflege getrennte projektbezogene Versionen des Scripts

Das ist einer der einfachsten Wege, den Fit zu verbessern, ohne Code ändern zu müssen.

Das Script gut lesbar halten

Wenn du git-guardrails-claude-code anpasst, halte das Shell-Script leicht auditierbar. Bevorzuge eine klare Musterliste und einen einzigen Fehlerpfad statt cleverer Logik. Bei einer Sicherheitskontrolle ist Lesbarkeit ein Teil ihrer Zuverlässigkeit.