Crew git
Use whenever committing, branching, or repairing git history. Enforces atomic commits, the staged-diff read-through, honest messages, and the safe-repair table (including the rotate-first rule for leaked secrets).From its SKILL.md
npx -y skills add Honorboxx/crew --skill crew-gitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.3 KB, 783 tokens by cl100k_base, as published. Nobody here has run it
crew-git: history as a communication act
A commit is not a save point; it's the unit someone else reviews, bisects,
reverts, and reads in git blame three years from now. Hygiene here is not
tidiness; it's making every one of those four operations work.
Committing
- One logical change per commit. The operational test isn't "is it small"
but "can it be reverted alone without collateral damage". Mechanical noise
(rename, format, lockfile churn) goes in its own commit, separated from
behavior. A reviewer can wave through a pure-rename commit in seconds if
it's pure, and
git bisectstays sharp. - Read the staged diff before every commit.
git diff --staged, every hunk, in the terminal. The medium switch from your editor resets pattern-blindness. This is where debug prints, stray files, commented-out code, and "how did THAT get staged" are caught. Stage deliberately (git add -pwhen the tree is mixed), nevergit add -Aout of habit. - Message = why, not what. The diff already says what. Imperative subject ≤ 72 chars; body for the why, the alternative you rejected, and any non-obvious consequence. If the subject needs "and", split the commit.
- Never commit: secrets, generated files the repo doesn't already track,
half-done work on a shared branch.
WIPcommits are fine on your own branch if they're squashed before review.
Branching
Branch per task, from up-to-date main. Never commit to main by habit: if the repo allows it, that's the repo being polite, not it being a good idea. Rebase your own unshared branch to stay current; never rewrite anything already pushed to a branch others use. Whether the repo merges or rebases onto main is the repo's convention, not yours to relitigate mid-PR.
Safe repair table
| Situation | Repair |
|---|---|
| Committed too soon, not pushed | git commit --amend / git rebase -i freely |
| Committed too soon, already pushed to shared branch | New commit on top; amending pushed history transfers your mistake to everyone's clone |
| Wrong branch | git cherry-pick onto the right one, then remove from the wrong one |
| Need to undo a pushed commit | git revert (an honest new commit, history intact) |
| Staged/tracked file that must never be | remove + .gitignore in the same commit, or it returns |
| Secret committed | Rotate the secret FIRST. History rewriting comes second and only for tidiness. Clones, forks, and CI logs already have the value, so scrubbing without rotating is theater |
| Detached HEAD / "everything is gone" | git reflog. It's almost never gone; find the SHA, branch from it |
Failure modes
| Habit | Cost |
|---|---|
git add -A && git commit -m fix | Unreviewable history; bisect finds "fix" |
| Force-push to a shared branch | Everyone downstream rebases their morning away |
| Mixing rename + logic in one commit | Reviewer must diff-in-head the rename to see the logic |
| Amending as amnesia (repeatedly rewriting local history mid-debug) | You destroy the trail git bisect needed |
| Commit message novel for a typo fix | Effort budget spent where nobody needed it |
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 1 of the 12 instructions most pr commit review skills give in 783 tokens
Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07
- Use conventional commits formatin 127 of 888, across 115 files
- Keep subject line under 72 charactershere, and in 62 of 888, across 48 files
- Delete branches after mergein 51 of 888, across 38 files
- Use imperative mood in subject linein 51 of 888, across 42 files
- Use imperative mood in commit messagesin 44 of 888
- Verify directory is ignored before creating worktreein 43 of 888, across 12 files
- Generate a conventional commit messagein 43 of 888
- Add unignored worktree directories to gitignorein 42 of 888, across 10 files
- Make atomic commitsin 39 of 888, across 27 files
- Run tests before committingin 36 of 888, across 25 files
- Verify clean test baselinein 35 of 888, across 9 files
- Split unrelated changes into separate commitsin 35 of 888, across 30 files
Said here and by no other author read
- stage files deliberately
- split commit if subject needs and
- branch per task from updated main
- use git reflog to recover detached head states
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.