From safe-git-operations
Use before running git reset, git add -A/./-a, editing .gitignore when it's not excluding expected paths, or cleaning up committed files. Prevents four common operational failure modes that cascade into long recovery sessions: reset without state check, catchall staging of build artifacts, gitignore pattern trial-and-error, and per-file iteration when a single bulk command suffices.
How this skill is triggered — by the user, by Claude, or both
Slash command
/safe-git-operations:safe-git-operationsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Operational safety rules for common git commands where mistakes cascade. Complements `git-workflow` (which covers branching, commits, PR/CI workflow) by addressing **what not to do** in specific risky situations.
Operational safety rules for common git commands where mistakes cascade. Complements git-workflow (which covers branching, commits, PR/CI workflow) by addressing what not to do in specific risky situations.
git resetBefore any git reset command — hard, soft, or mixed — run a state check first. Guessing HEAD~N is the single most common cause of multi-minute recovery cycles.
Check first:
git log --oneline | head -10
Then:
HEAD~N only after confirming the branch has at least N+1 commitsNever do this:
git reset HEAD~3 # ❌ did you verify there are 3+ commits?
git reset --hard HEAD~N # ❌ doubly dangerous — discards working tree too
If reset already went wrong: git reflog shows every HEAD move and lets you recover. Don't panic-try more resets.
git add -A, git add ., git commit -a are anti-patterns when the working tree is not clean. They pick up whatever is dirty — build artifacts, editor backup files, IDE caches, accidental files — and put them in the commit.
Always verify first:
git status --short
Read every line. If anything unintended is staged or modified:
.gitignore first (see Rule 3)git add <specific files> or git add -p for interactive staginggit status --short shows only intended changesException: For tiny repos with a known-clean tree (e.g., a fresh clone, working on a brand-new branch with zero build artifacts), catchall staging is fine. In any real project with builds, tests, or generated files, it is a trap.
git check-ignore to debug .gitignoreWhen a .gitignore isn't excluding expected paths, DO NOT iterate by trial and error on trailing slashes, glob patterns, or negation rules. git has a debug command specifically for this:
git check-ignore -v <path>
Output shows exactly which rule (file, line number) matches — or nothing if no rule matches.
Example:
$ git check-ignore -v build/output.o
.gitignore:3:build/ build/output.o
This tells you: line 3 of .gitignore contains build/ and it matches this file. Done in one command.
Common mistake: Toggling .build vs .build/ in the gitignore. Both work — .build matches both files named .build and directories named .build; the trailing slash only narrows to directories. The real issue is almost always path placement: a .gitignore inside OllamaStatusMenu/ containing OllamaStatusMenu/.build/ is doubly-prefixed and never matches anything. git check-ignore -v surfaces this instantly.
If hundreds of files were accidentally committed (e.g., a .build/ tree, node_modules/, an editor's cache), do NOT iterate git rm per file. A single recursive command suffices:
# Unstage a directory tree from the index (keeps working-tree files):
git rm -r --cached <dir>
# Also delete them from the working tree:
git rm -r <dir>
For build artifacts that are already in .gitignore but appear in the index (because they were added before the gitignore rule existed), the canonical fix is:
# Unstage everything, then re-add using current .gitignore rules
git rm -r --cached .
git add .
Never iterate per-file git rm 'foo/bar/baz' — this is O(n) in time, generates enormous log output, and tends to trigger inference timeouts or context exhaustion on agent systems.
Ask yourself before any of these:
git reset? → apply Rule 1-A / . / -a? → apply Rule 2.gitignore because something isn't excluded? → apply Rule 3If yes, follow the rule. These four are the "mistakes that cascade" pattern: a small error here turns a 30-second task into a 30-minute recovery.
git-workflow-skill for branching, commits, PRs, CI/CD.gitignore in the first placeGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub paretofilm/claude-marketplace --plugin safe-git-operations