git-guardrails-claude-code

git-guardrails-claude-code スキルの概要

git-guardrails-claude-code は、Claude Code が破壊的な Git コマンドを実行する前に、あらかじめ拒否させるためのスキルです。役割は明快で、AI によるコーディング作業中に git push、git reset --hard、git clean -f、git branch -D によるブランチ削除、さらに git checkout . や git restore . によるワーキングツリーの変更消去を、うっかり実行できないよう安全層を追加します。

git-guardrails-claude-code を使うべき人

このスキルが特に向いているのは、次のような人です。

• Claude Code を実際のリポジトリに対して直接使っている
• AI の支援は欲しいが、Git の取り返しのつかない操作は任せたくない
• 共有リポジトリ、本番系リポジトリ、クライアント案件のコードベースで作業している
• 「気をつけて」と促すだけでなく、ローカルで強制できる仕組みを重視している

エージェント実行中の誤操作によるコード破壊や、許可していない push を一番の懸念としているなら、git-guardrails-claude-code はかなり相性の良い選択です。

普通のプロンプトと何が違うのか

通常のプロンプトでも、Claude に危険なコマンドを実行しないよう依頼することはできます。ただし、プロンプトはあくまで“お願い”であり、強制力は弱めです。git-guardrails-claude-code は PreToolUse hook を使うため、制約が会話上の指示ではなく、Claude Code の実行経路そのものに入ります。ここが最大の違いであり、このスキルを入れる一番の理由でもあります。

実際にブロックする内容

同梱のシェルスクリプトは、これから実行される Bash コマンドを確認し、以下のようなパターンをブロックします。

• git push
• git reset --hard
• git clean -f
• git clean -fd
• git branch -D
• git checkout .
• git restore .
• push --force のような force-push 関連の一致

ブロック時のメッセージでは、そのコマンドを使う権限が Claude にはないことが伝えられます。

このスキルでできないこと

git-guardrails-claude-code は、Git 全体のポリシー管理を担う仕組みではありません。次のようなことは行いません。

• commit の品質チェック
• 承認フローの強制
• 安全な push 先と危険な push 先の判別
• リポジトリ固有のブランチ運用ルールの理解
• スクリプトに書かれていないパターン外のコマンド保護

導入前にここは重要です。これは包括的なガバナンスではなく、危険な操作を絞って防ぐためのガードレールです。

git-guardrails-claude-code スキルの使い方

まず先に適用範囲を決める

上流のスキルで最初に判断すべき実務的ポイントは、このガードレールをどこに適用するかです。

• このプロジェクトだけ .claude/settings.json に入れる
• すべてのプロジェクト に対して ~/.claude/settings.json に入れる

この選択によって、スクリプトのコピー先も、ブロックが効く範囲も変わります。多くのチームでは、まずプロジェクト単位で導入したほうが検証しやすく安全です。同じ Git 制限をどこでも使いたいと分かっているなら、グローバル導入が向いています。

先に読むべきファイル

重要なポイントは、次の 2 ファイルを見るだけでほぼ把握できます。

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

この順で読むのが有効です。SKILL.md では hook のつなぎ方が説明され、scripts/block-dangerous-git.sh では何をどの条件で止めるのかがそのまま確認できます。誤検知や抜け漏れが気になるなら、文章説明よりスクリプト本体のほうが重要です。

git-guardrails-claude-code のインストール概要

git-guardrails-claude-code install は、Claude Code の hook システムに対する手作業のセットアップが中心です。

1. シェルスクリプトを hooks ディレクトリにコピーする
2. 実行権限を付ける
3. PreToolUse の Bash matcher に登録する

元スクリプトのリポジトリ内パスは次です。

scripts/block-dangerous-git.sh

配置先は以下です。

• project scope: .claude/hooks/block-dangerous-git.sh
• global scope: ~/.claude/hooks/block-dangerous-git.sh

そのうえで実行権限を付与します。

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

グローバル適用ならこちらです。

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

Claude Code の hook を正しく追加する

プロジェクト単位では、このスキルは .claude/settings.json に PreToolUse hook を追加し、コピーしたスクリプトを "$CLAUDE_PROJECT_DIR" 経由で実行する形を案内しています。

配線上の重要ポイントは次のとおりです。

• hook event: PreToolUse
• matcher: Bash
• hook type: command
• command: block-dangerous-git.sh へのパス

この hook が PreToolUse に登録されていないと、スクリプトのファイル自体が存在していても、コマンドを横取りして止めることはできません。

git-guardrails-claude-code のスクリプトは実際にどう動くか

このシェルスクリプトは標準入力からツール入力を受け取り、jq で .tool_input.command を取り出し、危険なパターンの小さな配列と grep -qE で照合します。

つまり、導入時に詰まりやすい条件はかなり明確です。

• 環境に jq が入っていること
• settings 内のコマンドパスが正しいこと
• スクリプトに実行権限があること
• Claude Code が本当に Bash ツール呼び出しを hook 経由で通していること

このどれかが欠けると、守られているつもりでも実際の保護は想定より弱くなります。しかも静かにそうなるので注意が必要です。

このスキル導入前に決めておきたいこと

上流のスキル自体が要求する前提情報は多くありませんが、git-guardrails-claude-code usage をうまく回すには、少なくとも次を決めておくと運用がぶれません。

• project-only にするか global にするか
• デフォルトのブロック対象で足りるか
• git tag -d、git rebase --abort、特定リモート向け push なども止めたいか
• 正当な push が必要なときに、人手でどうエスカレーションするかを明文化するか

この整理なしでもインストール自体はできますが、実運用でポリシーとのズレが出やすくなります。

曖昧な依頼を、失敗しにくいプロンプトに変える

弱いプロンプト:

• 「Set up git guardrails.」

より良いプロンプト:

• 「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.」

これが良い理由は次のとおりです。

• 適用範囲が明確
• 配置先が指定されている
• セットアップと検証の両方を要求している
• Claude が別の hook 構成を自己判断で作る余地を減らせる

最初の導入で失敗しにくい進め方

実用的な git-guardrails-claude-code guide は、次の順番です。

1. project か global かを決める
2. scripts/block-dangerous-git.sh を確認する
3. スクリプトを対象の hooks ディレクトリへコピーする
4. コピー先ファイルに chmod +x を付ける
5. 正しい settings ファイルに PreToolUse hook を設定する
6. 安全なリポジトリで無害なシミュレーション、または明らかにブロック対象のコマンドで試す
7. パターンをカスタマイズするか判断する

この順番が重要なのは、広く展開する前に、何が実際に強制されるのかを先に確認できるからです。

インストール確認は「ファイルがある」だけで終えない

「ファイルが置けた」で止めず、挙動を確認してください。

• Claude Code が実際に参照している settings ファイルのパスを確認する
• hook の command が、リポジトリ内の元ファイルではなく、コピー先スクリプトを指していることを確認する
• 使い捨てのリポジトリでブロック対象パターンを発火させる
• コマンドが実行されるのではなく、Claude 側に拒否が返ることを確認する

このスキルでは、見た目の確認より挙動確認のほうが重要です。

git-guardrails-claude-code が向く Git ワークフロー

git-guardrails-claude-code for Git Workflows が特にハマるのは、次のような AI 活用フローです。

• Claude には自由にファイル編集させる
• diff や status の確認は Claude に任せる
• ブランチ削除、force push、hard reset、cleanup 系コマンドは人間が明示的に扱う

この分担は、コーディング作業の生産性は保ちつつ、取り返しのつかないリポジトリ操作だけを手動に残せる点でバランスが良いです。

スクリプトをカスタマイズすべきタイミング

デフォルトのブロック一覧は意図的に狭めです。次のような場合は scripts/block-dangerous-git.sh を調整する価値があります。

• git push 自体は許可したいが、--force だけ止めたい
• git commit --amend もブロックしたい
• ブランチ削除に関して独自のセンシティブなパターンがある
• リポジトリごとに異なるルールにしたい

ここでの主なトレードオフは、シンプルさと精度です。標準スクリプトは監査しやすい一方、大きくカスタマイズしたものはそのぶんテストが必要になります。

git-guardrails-claude-code スキル FAQ

git-guardrails-claude-code は初心者にも向いているか

はい。前提として Claude Code をすでに使っていて、Git 周りの初期安全性を高めたい初心者には向いています。セットアップは短く、考え方も分かりやすいです。やっていることは「Bash ツール呼び出しを実行前に止める」だけです。少しだけ技術的なのは、JSON の hook 設定とシェルスクリプトの実行権限くらいです。

Claude に「never push」と言うだけより良いか

はい。このスキルがカバーするコマンドに限れば、明確に良いです。git-guardrails-claude-code は、会話上のルールを実行時チェックへ変えます。プロンプト記憶に頼るより、信頼性はずっと高くなります。

git-guardrails-claude-code は危険な Git コマンドを全部止めるか

いいえ。止めるのは、あくまでスクリプトに明示されているパターンだけです。自分たちのリスクモデルに別のコマンドが含まれるなら、自分で追加する必要があります。ここはこのスキルの重要な境界です。

git-guardrails-claude-code をグローバルに使えるか

はい。~/.claude/settings.json と ~/.claude/hooks/block-dangerous-git.sh を使うグローバル導入を明示的にサポートしています。グローバル導入は便利ですが、検証しやすさや、リポジトリごとに違うポリシーへ対応しやすい点では project-only のほうが安全です。

普段のコーディング作業を邪魔しないか

通常は大きな支障にはなりません。普段のワークフローで Claude に push や破壊的な Git cleanup をさせないなら、影響は限定的です。Claude にはコード編集、テスト実行、変更準備まで任せ、人間が最終的な Git 権限を持つ運用と特に相性が良いです。

どんな場合はこのスキルを使わないほうがいいか

次のような場合は git-guardrails-claude-code は見送ったほうがよいです。

• Claude に Git を最初から最後まで管理させたい
• 単純なパターンブロックではなく、細かな allowlist が必要
• シェル hook や jq を前提にできない
• ローカルな Claude Code 設定を超えて、組織全体で強制したい

こうした条件では、このスキルは機能が狭すぎる、あるいはローカル寄りすぎると感じやすいです。

git-guardrails-claude-code スキルを改善する方法

ブロック対象パターンを実際のリスクと照らし合わせる

git-guardrails-claude-code を最も手早く改善する方法は、デフォルトのパターン一覧と、自分たちが本当に避けたい Git ミスを比較することです。多くのチームでは、単にすべての push を嫌うというより、次のような操作を特に重く見ています。

• force push
• 保護対象ブランチでのブランチ削除
• monorepo での破壊的 cleanup
• デバッグ中のワーキングツリー reset

もし自分たちのポリシーが違うなら、デフォルトをそのまま受け入れるのではなく、パターン配列を編集するべきです。

Claude へのインストール指示をもっと具体的にする

Claude にこのスキルを適用させるなら、依頼文に具体情報を含めてください。

• 適用範囲
• 正確な配置先パス
• 既存 hook を保持するのか、マージするのか
• 最終的な JSON ファイルをレビュー用に出力するか
• セットアップ後に hook をテストするか

より強い依頼例:

• 「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.」

これで避けやすくなるのが、典型的な失敗のひとつである「既存の hook 設定を上書きしてしまう」問題です。

hook のマージミスに注意する

現実的によく起きる問題は、シェルスクリプト本体ではなく settings ファイル更新のほうです。リポジトリにすでに hooks 設定がある場合、雑な導入で上書きされることがあります。次のように依頼すると安全です。

• 全文上書きではなく diff を出してもらう
• 既存の PreToolUse エントリを保持させる
• 複数 command が走る場合の hook 順序を説明させる

多くのユーザーにとっては、ブロック対象コマンド一覧よりこちらのほうが重要です。

誤検知とすり抜けをテストする

このスクリプトはパターンマッチで動くため、次をテストすべきです。

• 通過してよい正当なコマンド
• 失敗すべきブロック対象コマンド
• 止まると思っていたが実は止まらないバリエーション
• 似た文字列を予想外の形で含むコマンド文字列

git-guardrails-claude-code usage への信頼性を高めるなら、特にグローバル展開前にここを詰めるのが正しい進め方です。

実際の取りこぼしを見てからスクリプトを厳しくする

最初から大量のパターンを追加したくなるかもしれませんが、根拠がないうちは避けたほうがいいです。短く読みやすい blocklist のほうが、信頼しやすく保守もしやすいからです。広げるのは、次のような観察があってからで十分です。

• Claude が実際によく試すコマンド
• ユーザーが危険とみなすコマンド
• すり抜けたパターン
• 本来は許可したいのにブロックされたコマンド

そのほうが、ガードレールの意図を保ったまま理解しやすく運用できます。

人手でのエスカレーション経路を用意する

運用面での良い改善は、このガードレールと明確なルールをセットにすることです。たとえば次のような形です。

• Claude は commit の準備と push 手順の説明までは行ってよい
• 最終的な push や破壊的 cleanup は人間が手動で行う

こうしておくと、ユーザーがガードレールと戦うのではなく、最初からそれを前提に作業設計するようになります。

グローバル適用かプロジェクト限定かを見直す

使い始めた後は、適用範囲を改めて評価してください。

• どのリポジトリでも同じルールで良いなら global に移す
• 一部のリポジトリでは Git の自由度が必要なら project-local のままにする
• チームごとに違うなら、プロジェクト単位で別バージョンのスクリプトを維持する

コードを変えなくても、適合性を上げる最も簡単な改善策のひとつです。

スクリプトは読みやすく保つ

git-guardrails-claude-code をカスタマイズする場合でも、シェルスクリプトは監査しやすい状態を保ってください。複雑で巧妙なロジックより、明確なパターン一覧と単一のエラーパスのほうが適しています。安全装置では、読みやすさそのものが信頼性の一部です。