git-safety

Stops an agent from destroying uncommitted work with git. Requires git status and git diff before any command that discards changes, treats "revert" and "undo" as manual edits, and never runs reset, checkout, clean, stash drop, or force push without explicit approval. Use when a task involves reverting, undoing, resetting, cleaning, rebasing, or force pushing, or before any git command in a repo with uncommitted changes.

Quality

98%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Git safety

These rules exist because one git checkout -- . erased two days of work. Follow them every time, not only when it feels risky.

Before any git command

git status. Read it.
If anything is modified or untracked, stop. Say what is there. Ask before proceeding with anything that could touch those files.
Suggest git stash push -m "<why>" if the user needs a clean tree and wants the work kept.

Commands that need explicit approval

Never run these on your own. Show the exact command, say what it will destroy, and wait for a yes.

Command	What it destroys
`git reset --hard`	every uncommitted change
`git checkout -- <file>` or `git restore <file>`	uncommitted changes in that file
`git checkout -- .` or `git restore .`	uncommitted changes in every file
`git clean -fd`	every untracked file and folder
`git stash drop` or `git stash clear`	stashed work
`git push --force` or `--force-with-lease`	remote history other people may have
`git branch -D`	a branch and any commits only it holds
`git rebase` on a shared branch	commit ids other people have

"Explicit approval" means the user saw the command and said yes to it. A general "go ahead" from earlier in the conversation does not count.

Revert and undo mean edit

When the user says "revert that", "undo that", or "go back":

Ask which change. Committed or uncommitted? All of it or one part?
git diff <file> to see exactly what would be lost.
Read the current file.
Edit the file by hand to remove the specific lines that are wrong. Keep everything else.
Show the result.

Do not reach for git checkout or git restore. They remove everything in the file, including the parts the user liked.

For committed changes, git revert <sha> is safe because it creates a new commit. Still show the sha and the commit message first.

Diff before discard

Any time a change is about to be thrown away, the user sees git diff output for it first. No exceptions. If the diff is long, show git diff --stat and offer the full diff.

Commits, pushes, deploys

Do not commit, push, tag, publish, or deploy unless the user asks in the current message. When the work is done, print a suggested commit message and stop.

Suggested commit:
fix: dedupe heartbeat writes within 10s window

Safe defaults

These are fine to run without asking:

git status, git log, git diff, git show, git blame
git stash push -m "<message>" when the user asked for a clean tree
git add <specific files> when the user asked to commit
git checkout -b <new-branch> from a clean tree
git revert <sha> after showing the commit

Checklist

Before a git command:

git status ran and I read it
no uncommitted work is in the blast radius, or the user approved
I showed git diff for anything being discarded
the command is not in the approval table, or the user said yes to this exact command

When asked to revert or undo:

I know which change and whether it is committed
I am editing the file, not checking it out
everything the user did not mention stays

Repository: waynesutton/convexskills
Path: skills/git-safety/SKILL.md
Commit: 82d1ce2

Last updated: 1 day ago
First committed: 7 days ago

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.