| name | git-safe |
| description | Safety rules for destructive/history-rewriting git ops (force push, reset --hard, clean -f, branch -D, checkout over uncommitted changes, rebase/amend of pushed work) plus this repo's canonical commit hygiene. Trigger before any such command, or before any skill runs `git commit`. |
Git Guardrails
Destructive and history-rewriting git commands need a check before they run, not after. This skill is a pre-flight gate, not a workflow — it fires in the moment right before one of the commands below.
Gated commands
For each, check state first, then confirm with the user before running — unless the user has already explicitly authorized this exact action in this conversation.
| Command | Check first | Why |
|---|
push --force / -f | git log origin/<branch>..<branch> and <branch>..origin/<branch> — is anyone else's work on the remote tip? | Force push can silently discard commits others pushed. |
reset --hard | git status — anything uncommitted? git log — anything on this branch not merged elsewhere? | Uncommitted and unreachable-after-reset commits are gone. |
clean -f / -fd | git clean -ndx (dry run) to list what would be deleted | Untracked files are not recoverable from git after this. |
checkout -- <path> / restore <path> | git diff <path> — is this discarding real edits? | No undo once the working-tree change is gone. |
branch -D | git branch --merged — is the branch actually merged? | -D skips the safety check -d does. |
rebase on a branch already pushed | git ls-remote --heads origin <branch> or check for open PRs on it | Rewrites history others may have already pulled or reviewed. |
commit --amend on a pushed commit | Is this commit only local, or already on the remote? | Amending a published commit forces everyone downstream to rebase. |
filter-branch / filter-repo / any full-history rewrite | Confirm scope and that all collaborators know | Rewrites every commit hash on the branch. |
Rules
- Never chain a gated command automatically after another command "to clean up" — each one gets its own check.
git status before any operation that could discard uncommitted work, every time, not just when something looks off.- If a lock file (
.git/index.lock) or unfamiliar branch/stash exists, investigate what put it there before removing it — it may be another process's in-progress work.
- Prefer a reversible step over a destructive one when it gets to the same result:
git stash over git checkout --, rename/move over rm, git revert over reset --hard on shared branches.
- A user approving one destructive command once is not standing approval for the same command later in the session — confirm scope each time, unless they've said "always do X without asking" for this repo.
- Never add
--no-verify, --no-gpg-sign, or skip hooks to route around a failure — fix what the hook caught.
- Never force-push to
main/master — refuse and explain, even if asked, unless the user overrides explicitly after being told the risk.
Commit hygiene
Every git commit in this repo's skills follows this, no exceptions:
git add -u for tracked files, explicit paths for new files. Never git add -A — review git status first, stage only what the task touched.- No
Co-authored-by: trailer, ever — not even when a sub-agent or the harness did the work.
- Subject line ≤72 chars, imperative mood, why-focused not what-focused (e.g.
fix: prevent double-charge on retry, not fix: added a check).
- Conventional type prefix matching the change:
feat:, fix:, docs:, refactor:, test:, plan:, chore:.
- One logical change per commit — a plan phase, a review-finding fix, a doc update — not a grab-bag.
- Nothing git-visible names the tooling. Subjects, branch names, and PR titles never mention a skill, loop, iteration, phase number, finding ID, or workflow status:
fix: reject expired refresh tokens, not fix: address HIGH-002 from iteration 3. That bookkeeping stays in the artifacts, where it's still findable; history reads the same whether a human or this plugin wrote it.
- This is the canonical convention other skills point to instead of restating it; see
skills/dev/dev-implement-plan/SKILL.md §3 and skills/dev/dev-create-plan/SKILL.md for it applied to phase commits and plan-status commits.
Stacked PRs
full/ultra stacks are built with the gh-stack skill (gh extension install github/gh-stack), not hand-chained gh pr create --base — it owns the bases, the rebases, and the GitHub stack object. Invoke that skill for the full command set; the essentials, always non-interactive:
gh stack init <feature-name>/<first-slug>, then gh stack add <feature-name>/<next-slug> from the top branch for each later phase. Names are used verbatim, so pass the full branch name.gh stack submit --auto after each phase commit — pushes every branch, opens/updates each PR against the right base (--open for ready-for-review instead of draft).gh stack sync after anything merges (--prune to drop merged locals); gh stack view --json to read state — never bare, it opens a TUI; gh stack merge --yes to land the stack, since gh pr merge can't.- Need a change in a lower layer:
gh stack down (or checkout), commit it there, gh stack rebase --upstack, then back up. Never patch it at the top.
- Extension unavailable → fall back to
git push -u origin <branch> + gh pr create --base <previous-branch> per phase.
The gated commands above still apply inside a stack: gh stack rebases and force-with-lease pushes branches, so it is safe on your own stack and dangerous on one someone else is reviewing.
What this skill does not gate
Regular commits, regular (non-force) pushes to a branch only you use, fetch, merge, and reads (log, diff, show, status) need no confirmation — gating those would just be noise.
