auto-gitlisted

Set up automatic, per-round git commits for a code project so the user's work is committed every round and never lost. It runs git init, writes a sensible .gitignore, installs a Stop hook that auto-commits each round (and pushes when an upstream is configured), and makes the initial commit — then keeps committing as work continues, and keeps the project's progress files (progress.md, plan.md, and the like) current each round. Trigger it proactively whenever a new code project is being started or scaffolded, even if the user never mentions git: when they describe or kick off building an app, tool, or library, create the first source files, or ask you to write a CLAUDE.md for a codebase. Also trigger on explicit requests such as /auto-git, "turn on auto commit", "set up version control", "commit my changes automatically as we go", or "stop losing my work". Lean toward activating at the start of a coding project rather than missing it. Do NOT trigger for one-off git actions — a single "commit this", "push my bra
hfjddjksaj/auto-git · ★ 0 · Code & Development · score 72

Install: claude install-skill hfjddjksaj/auto-git

# auto-git Automatic, per-round git safety net for code projects. The goal is simple: the user should never lose a round of work, and their history should be readable without them having to think about committing. ## The two-part design (read this first) This skill combines two mechanisms because they have different strengths: 1. **A Stop hook — the backbone.** A project-local `autocommit` hook commits any uncommitted changes after every round, automatically, whether or not anyone remembers, and pushes when an upstream is configured. The harness runs it, so it cannot be forgotten. This is what *guarantees* nothing is lost. An optional companion, `progress-check`, is offered separately during setup and **never installed by default** (see step 4): if a round changed files but left `progress.md` stale, it blocks the stop once with a reminder so you update the progress files while you still have the context (it never writes content itself, and a `stop_hook_active` guard means it can never loop). 2. **You writing real commit messages — the polish.** A hook is a dumb shell script; it can only write a generic timestamped message. A commit message that actually says what changed can only come from you, during the turn. So when you're working in an auto-git project, you commit meaningful changes yourself as the last step of a round. The hook then finds a clean tree and only handles pushing (or sweeps up anything you left behind). The res