Put git-guardrails on exec form, and say what monitors do instead

[jackyraimond]

Two leftovers from the merges of the last few days, both about the same rule.

git-guardrails was the last hook on shell form

It was merged the same day the exec-form rule was written, so it kept the form it was authored with. Every other hook has since moved over, which left it as the only one in the repo not following its own CONTRIBUTING.

{ "type": "command", "command": "python3",
  "args": ["${CLAUDE_PLUGIN_ROOT}/scripts/git-guardrails.py"],
  "if": "Bash(git *)", "timeout": 10 }

if and timeout are untouched.

Monitors cannot follow that rule, and the wording did not say so

The bullet reads as applying to everything a plugin here ships. A monitor cannot comply: a monitors.json entry is name, command, description and an optional when. There is no args, and command is always handed to a shell — the plugins reference documents exactly the quoted "${CLAUDE_PLUGIN_ROOT}"/scripts/... form both monitors here already use.

So every monitor in the repo looked like it was out of line with a rule it had no way to satisfy. The bullet now splits into the hook case and the monitor case, and gives the monitor form its own example. No monitor changes.

Testing

./scripts/validate.sh and ./scripts/pr-policy.sh pass; pr-policy reports one hook touched, as an edit.

Exec form runs python3 <script> rather than the path alone, so the hook was exercised that way:

$ echo '{"tool_name":"Bash","tool_input":{"command":"git push --force origin main"}}' \
    | python3 hooks/git-guardrails/scripts/git-guardrails.py
Blocked by git-guardrails: force push to protected branch 'main'
exit=2

Still blocks, still exit 2.

Review notes

The hook change is behaviour-preserving in principle — same interpreter, same script, one less trip through sh -c. Worth confirming with /hooks after install that it still registers, since that is the one thing a local run cannot show.

🤖 Generated with Claude Code