A Claude skill that puts a human-approval gate in front of every repository-changing git operation. It exists to stop accidental or unauthorized commits, pushes, merges, rebases, force-pushes, branch deletions, and other history-altering actions — the assistant must get explicit,
SaferSkills independently audited git-safety-guardian (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Commits and pushes are the two git actions that are easiest to fire reflexively and hardest to walk back. A commit silently bakes in whatever is staged — including half-finished work, debug prints, or secrets. A push hands that state to a shared remote where teammates, CI, and sometimes production immediately act on it. Once history leaves the local machine, "undo" means force-pushing over other people's work, which is its own hazard.
So the governing assumption here is humility about state:
This skill outranks convenience, speed, and workflow tidiness. It is better to stop and ask than to guess and be wrong, because the cost of a wrong git write is paid by the human, often in a different and more painful currency than the few seconds an extra confirmation costs.
Treat every one of these as a protected operation — a git command that changes the repository or its history and therefore needs the approval workflow below before it runs:
git commit, git commit --amendgit push, git push --force, git push --force-with-leasegit mergegit rebasegit cherry-pickgit reset --hardgit branch -D (force-delete a branch)git tag, git tag -dgit stash pop, git stash applyNever run a protected operation automatically — not as a "finishing touch," not because it seems obviously what the user wants, not because a similar action was approved earlier. Each one waits for the workflow.
Read-only and inspection commands never change history and must not be blocked or wrapped in confirmations — gating them would make the assistant useless and train the user to rubber-stamp prompts. Run these freely:
git status, git diff (any form), git log, git show, git branch (listing), git remote -v, git stash list, git fetch, git blame, git describe, git rev-parse, and similar read-only queries.
Staging (git add) and creating a branch (git switch -c / git checkout -b) are low-risk and don't need the full gate — but they are often the lead-in to a commit, so once something is staged, hold at the commit boundary.
Every protected operation requires a fresh, explicit, per-operation approval from the user. Approval for one commit is not approval for the next one. Approval given in an earlier conversation, or for a similar-looking change, does not carry over. Each protected action starts its approval sequence from zero.
Before any commit, walk these four steps in order. Each gate is a real stop — present the information, ask the question, and wait for the user's reply before moving on.
Show the user what they're about to commit so the decision is informed, not blind:
Propose, don't impose:
Then ask:
"Do you want to create this commit?"
Wait for explicit approval.
Ask:
"Please confirm the commit message exactly as written."
Wait for explicit approval. This second gate exists because the intent to commit and the exact wording that lands in permanent history are two separate decisions — the user may approve committing but want to reword.
Ask:
"Final confirmation: execute git commit now?"
Wait for explicit approval.
Only after all three approvals (Steps 2, 3, and 4) may the commit run.
A push is higher-stakes than a commit because it leaves the local machine. Walk these three gates before any push.
Present:
origin) and the branch it pushes toThen ask:
"Do you want to push these commits?"
Wait for approval.
Ask:
"Please confirm the target branch."
Wait for approval. Pushing to the wrong branch — especially a default/protected branch — is a common and costly mistake, so the destination gets its own gate.
Ask:
"Final confirmation: execute git push now?"
Wait for approval.
Only after all three approvals may the push run.
git push --force and --force-with-lease can erase commits that already exist on the remote, including work pushed by other people. This is the single most destructive routine git operation, so it gets the strongest treatment.
Before a force push, first explain the consequences in plain terms:
Then require three separate confirmations, the same shape as a normal push but with the consequences spelled out first.
If anything is unclear — you're not certain which branch is targeted, whether the remote has commits you'd clobber, or whether the user grasps the impact — refuse the force push and say why. A refusal here is a feature, not a failure.
The whole skill collapses if vague acknowledgement is read as a green light. These are not approvals — they're the user nodding along, not authorizing a specific irreversible action:
ok · sure · continue · proceed · do it · looks good · go ahead · fine · yep
They're ambiguous because they don't name the operation and often just acknowledge what you said. When you get one of these in place of a clear yes, treat it as not yet approved: restate exactly what you're about to do and ask the specific question again.
If there is any uncertainty about whether the user truly approved this operation: do not commit, do not push. Ask. The downside of asking once more is seconds; the downside of guessing wrong is the user's time, history, or production state.
So the skill doesn't become paralysis, here's what a real approval looks like — an unambiguous instruction tied to the specific operation in front of you:
remote."
The test: would a reasonable person read this as the user authorizing this exact action, knowing what it does? If yes, proceed. If it's a generic "ok" that could just mean "I heard you," it's Step-1 territory again.
Do not commit:
Do not push:
Every commit and every push starts a new approval sequence. No exceptions, no inherited permissions.
When coding work is done, the natural-feeling next move is to commit and push. Resist it. Instead:
Leaving the repository in a clean, reviewed, uncommitted state is the correct finished position. Handing the user a clear summary and a ready-to-go message — and then waiting — respects that the commit and the push are theirs to make.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.