agentleFS
waynesuttonwaynesutton/convexskills/skills/git-safety/SKILL.md

git-safety

Skill405 starsChanged 45 days agoApache-2.0View on GitHub

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.

  • Deletes or force-pushes
  • Commits and pushes

11 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use verification-before-completion.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • OpenAISkill

    verification-before-completion

    Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If anything is modified or untracked, stop.

    line 13
  2. Distinctive:

    Never run these on your own.

    line 18
  3. Distinctive:

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

    line 35
  4. Distinctive:

    Ask which change. Committed or uncommitted?

    line 37
  5. Distinctive:

    Read the current file.

    line 39
  6. Distinctive:

    Do not reach for git checkout or git restore.

    line 43
  7. Distinctive:

    Do not commit, push, tag, publish, or deploy unless the user asks in the current message.

    line 53
  8. Distinctive:

    Before a git command:

    line 72
  9. Distinctive:

    When asked to revert or undo:

    line 79

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. git status. Read it.
  2. If anything is modified or untracked, stop. Say what is there. Ask before proceeding with anything that could touch those files.
  3. 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.

CommandWhat it destroys
git reset --hardevery 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 -fdevery untracked file and folder
git stash drop or git stash clearstashed work
git push --force or --force-with-leaseremote history other people may have
git branch -Da branch and any commits only it holds
git rebase on a shared branchcommit 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":

  1. Ask which change. Committed or uncommitted? All of it or one part?
  2. git diff <file> to see exactly what would be lost.
  3. Read the current file.
  4. Edit the file by hand to remove the specific lines that are wrong. Keep everything else.
  5. 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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.