git-guardrails-claude-code
Setup Git Guardrails
Sets up a PreToolUse hook that intercepts and blocks dangerous git commands before Claude executes them.
Invocation Position
This is an infrastructure safety skill, not a feature-delivery step.
Use /git-guardrails-claude-code when the project or user wants stronger protection against destructive git operations in Claude-driven workflows.
Do not treat it as part of the normal feature pipeline. It is a repo or user setup action that makes later work safer.
What Gets Blocked
git push --force/git push -f(regular pushes are allowed)git reset --hardgit clean -f/git clean -fdgit branch -Dgit checkout ./git restore .
When blocked, Claude sees a message telling it that it does not have authority to access these commands.
Steps
1. Ask scope
Ask the user: install for this project only (.claude/settings.json) or all projects (~/.claude/settings.json)?
2. Copy the hook script
The bundled script is at: scripts/block-dangerous-git.sh
Copy it to the target location based on scope:
- Project:
.claude/hooks/block-dangerous-git.sh - Global:
~/.claude/hooks/block-dangerous-git.sh
Make it executable with chmod +x.
3. Add hook to settings
Add to the appropriate settings file:
Project (.claude/settings.json):
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-dangerous-git.sh"
}
]
}
]
}
}
Global (~/.claude/settings.json):
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "~/.claude/hooks/block-dangerous-git.sh"
}
]
}
]
}
}
If the settings file already exists, merge the hook into existing hooks.PreToolUse array — don't overwrite other settings.
4. Ask about customization
Ask if user wants to add or remove any patterns from the blocked list. Edit the copied script accordingly.
5. Verify
Run a quick test:
# Should be BLOCKED (exit 2):
echo '{"tool_input":{"command":"git push --force origin main"}}' | <path-to-script>
# Should be ALLOWED (exit 0):
echo '{"tool_input":{"command":"git push origin feature/my-branch"}}' | <path-to-script>
The force-push command should exit with code 2 and print a BLOCKED message to stderr. The regular push should exit with code 0.
Handoff
- Expected input: a project or user environment that needs stronger git safety controls
- Produces: installed guardrail hooks and safer Claude git behavior
- Supports downstream: all implementation and review work by reducing destructive-command risk
- What comes next: return to normal workflow with the guardrails in place
More from chrislacey89/skills
pre-merge
Primary pipeline review step after verified implementation. Use to create a PR with lineage and run architectural review before merge. Not for QA intake, planning, or implementation work.
20execute
Primary pipeline execution step after /prd-to-issues or for clearly scoped implementation work. Use to build, verify, and commit a concrete slice, delegating to /tdd for backend work and behavior-heavy frontend logic when red-green-refactor will reduce risk. Not for shaping or pre-merge review.
19prd-to-issues
Primary pipeline decomposition step after /write-a-prd. Use when a shaped PRD is ready to become implementation-ready slices with boundary maps and dependency order. Not for unresolved scope, appetite, or solution direction.
12setup-ralph-loop
Infrastructure skill for setting up Ralph loop scripts for Claude-driven AFK execution. Use when a repo wants a HITL-to-AFK runner around /execute with bounded iterations, GitHub-native durable state, and explicit feedback loops. Not a normal feature-delivery stage; it prepares the repo for safer autonomous execution.
10help
Side-route orientation skill. Use when the user asks 'what's next', 'where am I', or is returning to a repo mid-pipeline and wants to know which skill to run next. Reads repo state (branch, PRs, issues, research archive, milestones) and recommends one next step with a one-line reason. Not for executing work — only for routing.
9triage-issue
Invoked helper skill for deep bug diagnosis, usually delegated from /qa when a reported issue needs root-cause analysis and a TDD fix plan before implementation. Use when the cause is unclear, the bug is a regression, or the user explicitly wants diagnosis. Not for lightweight QA intake (use /qa) or already-clear implementation tasks (use /execute).
9