agentleFS
Sign inStart free
adamentwistleadamentwistle/fable-skills/git-hygiene/SKILL.md

git-hygiene

Skill98 starsChanged 2 months agoMITView on GitHub

Version-control discipline — stage by explicit path, one logical change per commit with a why-message, branch before risky work, secrets never in history, no rewriting commits you don't own. Use when committing, staging, branching, amending, rebasing, stashing, force-pushing, writing commit messages, or starting any change large enough to want an undo point. Not for deciding what code to change.

  • Reads credentials

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Don't rewrite history you don't own: Before commit --amend, rebase, reset, or any force-push, run git log origin/<branch>..HEAD …

    line 25
  2. Distinctive:

    Never push, tag, or open a PR unprompted: When asked, name the exact remote and branch in the report.

    line 26

“Common” is measured: kept by at least 6 in 10 of the 3 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-hygiene

Weak git use looks like: git add -A && git commit -m "updates" on main, with a debug script and a .env riding along. Strong git use makes every commit a deliberate, reversible, explainable unit. Git is the safety net and the paper trail; each step below protects one or the other.

Before the work

  1. Check where you stand: git status and git branch --show-current. Pre-existing uncommitted changes and stashes are the user's — not yours to stage, revert, or drop (see data-loss-guard).
  2. Branch before risky or user-visible work, and never commit to main/master unprompted, even for "one small fix": git switch -c <type>/<short-slug> in the repo's naming style. A branch costs nothing; un-committing from main costs a conversation.
  3. Read history before "fixing" odd code: git log -S <symbol> --oneline and git blame -L <start>,<end> <file> on the lines you're about to change. If a past commit did it deliberately, its message says why — respect it, or cite it when overriding.

Staging

  1. Stage by explicit path, never by wildcard. git add <file> ... or git add -p; never git add -A or git add .. First list every untracked path in git status and decide each: intended artifact (stage), ignorable (add to .gitignore if the repo would want that), or debris you created (delete). Anything untracked you didn't create gets asked about, not committed.
  2. Scan the staged diff for secrets before committing: git diff --cached | grep -inE 'api[_-]?key|secret|token|passw|PRIVATE KEY|AKIA[0-9A-Z]{16}'. A hit means unstage and remove. A secret in an already-pushed commit is compromised even after amend or rebase — tell the user to rotate it; never present history rewriting as the fix.
  3. Read the staged diff top to bottom (git diff --cached) — the last cheap moment to catch debug prints, commented-out experiments, and unrelated hunks (see workmanship). Unrelated hunks go in a separate commit or stay unstaged.

Committing

  1. Commit only when asked, then one logical change per commit. Run git log --oneline -20 first and match the house style (prefix, tense, length). The subject states what and why for the person running git log during an incident: "fix utf8 filename crash in import", not "fix bug". Reasoning and behavior changes go in the body.
  2. Don't rewrite history you don't own. Before commit --amend, rebase, reset, or any force-push, run git log origin/<branch>..HEAD --format='%h %an %s': every commit you'd touch must be unpushed AND authored this session. Otherwise stop and ask. If a force-push is explicitly requested, use --force-with-lease, never --force.
  3. Never push, tag, or open a PR unprompted. When asked, name the exact remote and branch in the report.

Exit check

Report the branch, each commit hash and subject, and exactly what remains uncommitted or untracked and why. git status after your report should hold no surprises for the next person.

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.

Check your setup, free