git-commit skill

A skill that teaches coding agents to create git commits worth having: atomic, intentionally staged, conventionally formatted, and safe to make in a working tree that may contain someone else's uncommitted work.

Why

A git history is a communication medium, not a save file. Its consumers are reviewers reading a change commit-by-commit, future maintainers running git bisect and git blame, and tooling that derives changelogs and version bumps from commit metadata. Agents left to their own devices tend to produce histories that serve none of them: git add -A sweeps, mixed-purpose commits, stray debug scripts, and attribution footers advertising the tooling.

This skill exists to fix that. Its goals, roughly in order of importance:

1. Never commit work that isn't yours. The working tree — and the index — may contain changes from other people or other sessions. Ownership means positive knowledge ("I edited this file, for this reason"), not plausibility. Anything unaccounted for is left strictly alone and reported, never staged, reverted, or "cleaned up".
2. One commit, one logical change. Unrelated changes never share a commit even when they share a file (hunk-level staging handles that); related changes are never fragmented file-by-file. Commits are ordered so each leaves the repository working where feasible, keeping the history bisectable.
3. Staging is deliberate. No git add -A, git add ., git add -u, or git commit -a — ever. Files are staged individually, and every commit is preceded by a review of the staged diff, because staging is the moment responsibility for content is accepted.
4. Conventional Commits, matched to the repository's existing dialect of types and scopes rather than imposed abstractly.
5. No AI attribution. No co-author trailers for tools, no "generated with" lines, no badges. The human is the author of record and is responsible for the change regardless of what tools produced it; the repository is not advertising space.
6. No cruft. Temporary scripts, logs, and debug output created along the way are deleted before committing, not checked in.

The skill is written to teach reasoning rather than dictate rules — the intent is that an agent facing a situation the text doesn't cover can derive the right behavior from the goals above.

What's in it

skills/git-commit/
├── SKILL.md                          # principles and workflow
└── references/
    ├── conventional-commits.md       # message format, types, breaking changes
    └── partial-staging.md            # splitting one file's hunks across
                                      # commits, reliably and non-interactively

The partial-staging reference deserves a note: interactive git add -p is unreliable when driven by an agent (piping answers requires predicting git's hunk segmentation), so the skill uses a deterministic patch-based method — export the diff, trim it to the intended hunks, git apply --cached, verify — with git diff -U1 to separate adjacent changes and git add -N to extend the same workflow to untracked files.

Install

npx skills add HamStudy/git-commit-skill

Or copy skills/git-commit/ into wherever your tooling loads skills from.