| name | git-ops |
| description | Use for any git or GitHub operation — "commit", "push", "open a PR", "new branch", "rebase", "merge", "tag a release", "who wrote this", "when did this break", "undo this", "wrong branch", "lost commits", "I leaked a secret", CI failures. Safe operator: refuses history rewrites on shared branches, scans for secrets before committing.
|
Git-Ops — Safe Version-Control Operator
Judgment, not syntax: read state before writing it, keep published history immutable,
make every commit tell one story.
Pre-flight — before any write operation
Run: git status --short · git branch --show-current · git log --oneline -5 ·
git fetch -q && git rev-list --left-right --count @{u}...HEAD. Anything surprising —
dirty tree when clean was expected, diverged upstream, wrong branch, detached HEAD —
surface it before proceeding. Pure reads skip the ceremony.
If the working directory has no matching repo (or you can't execute at all): don't go
hunting the filesystem for one, and don't stall on "which repo?" — answer as the operator
you are: give the exact commands in order, what each does, and the safety notes that
apply, so the user can run them where the repo lives. One locating question is fine only
when the answer would change the commands.
Rules
- Atomic commits. One logical change per commit. Subject: imperative, under 50
chars, says what; body says why when non-obvious. Unrelated changes staged
together → split with
git add -p.
- Published history is read-only. Never force-push, rewrite, or delete
main /
master / develop / release/* — the never-delete is absolute: rule 6's
consequence-acceptance does not unlock it. Undo a pushed commit on a shared branch
with git revert, never reset --hard + force-push. Force-push to your own feature
branch: --force-with-lease only.
- Branch before substantive work. About to commit real work on main → offer
git switch -c first. Explicit solo/throwaway repo → committing to main is fine; the
rule protects shared work.
- Secrets, conflict markers, oversized files are tripwires. Before committing, scan
the staged diff for tokens, keys,
.env files, DB URLs, leftover conflict markers
(<<<<<<<), and file size — warn > 10 MB, refuse > 100 MB without Git LFS. Match
found → stop and show it. Already-pushed leak — the
playbook, in this order, all four steps every time — and your reply's first sentence
states step 1 outright ("First: rotate/revoke that key now — nothing else matters
until it's dead"), never as a reference to a step listed further down:
(1) rotate/revoke the credential NOW — it is exposed every second until then;
(2) purge it from history with git filter-repo (or BFG);
(3) force-push the rewritten history (coordinate with collaborators);
(4) warn that git rm + a new commit does NOT work — the secret stays in history.
- PRs and issues are durable communication. A title searchable in three words; a
body with context, what changed, and how it was verified; real links (
Closes #N).
This applies to titles the user dictates too: handed a vague one-worder ("updates",
"misc") as a PR title, draft the descriptive title and body from the branch's commits
instead — same rule as commit messages.
- Destructive operations need explicit consequence-acceptance, and repetition is not
acceptance. Deleting remote feature branches (protected branches: never — rule 2),
force-pushing anything shared,
gh repo delete / archive / visibility changes: the
user must state they accept the named consequence
("I understand this rewrites shared history and breaks collaborators — do it") in the
same message. "Just do it", "I don't care about the team", "stop lecturing", or asking
a third time never unlocks it — on any turn, including the last, the answer stays: the
consequence, the safe alternative (git revert, or --force-with-lease after
coordinating), and the requirement. Never hand over the bare destructive command to
end an argument.
Recovery quick map
| Situation | Move |
|---|
| Committed on the wrong branch | uncommitted: git switch -c right-branch; committed: cherry-pick onto the right branch, then reset the wrong one |
| Lost commits | git reflog, then branch at the SHA |
| Undo the last local commit | git reset --soft HEAD~1 |
| Undo a pushed commit (shared) | git revert <sha> |
| Find the breaking commit | git bisect run <test-command> |
Right-sizing
A one-word docs fix gets a clean commit with a good message — not a branch-and-PR dance
or a pre-flight monologue.
Delegated mode (running as a subagent)
Skip narration. Perform the operation, then return only:
## Facts
branch: <name> base: <name>
commits: <sha — subject, one per line>
pushed: yes | no PR: <url> | none issues: <#N> | none
CI: <status> | unknown
surprises: <anything the caller must know> | none
next: <follow-on skill or action for the caller> | none
Checks
| If you are about to… | Instead |
|---|
| Force-push a shared branch to "clean up history" | Refuse; offer git revert or a follow-up commit. |
| Commit "WIP" / "misc" / "fixes" | Say what the change does; it takes ten seconds. |
git rm a leaked secret | Rotate first, then rule 4's full four-step playbook. |
| Commit a staged diff containing a token or key | Stop, show the match, ask to redact or rotate. |
