agentleFS
sbrudzsbrudz/agent-skills/skills/git-commit-message/SKILL.md

git-commit-message

Skill2 starsChanged 9 months agoMITView on GitHub

Use when about to write a git commit message, before running git commit — applies when staged changes are ready and a message needs to be drafted

22 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use tdd.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use standard types (feat, fix, docs, refactor, chore, test, style, perf, ci, build), an optional scope (feat(auth):), and a !

    line 24
  2. Very specific:

    Keep harness-added Co-Authored-By trailers — don't strip them.

    line 26
  3. Distinctive:

    If yes → flag it: *"These look like separate logical changes — consider splitting into multiple commits."* Then still draft the message for …

    line 35
  4. Distinctive:

    When drafting a combined message: subject covers the most significant change.

    line 37
  5. Distinctive:

    No vague words without concrete detail: avoid *fix, update, change, improve, misc* as the entire subject — always follow them with what …

    line 46
  6. Distinctive:

    Why this approach?: If alternatives existed, why this one?

    line 59

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

A commit message is not a description of what changed — the diff already shows that. It's a record of why the change was made: the problem it solved, the constraint it respected, the decision it encoded. This skill guides writing messages that are useful months later to a reader with no context.

Step 1 — Match the Repo's Commit Convention

The repo's existing convention is the tiebreak: check recent history (git log --oneline -20) and any AGENTS.md/CONTRIBUTING guidance, and match what the repo actually uses.

Where the repo uses or requires Conventional Commits — and as the default when no convention is discernible — use:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Use standard types (feat, fix, docs, refactor, chore, test, style, perf, ci, build), an optional scope (feat(auth):), and a ! suffix or BREAKING CHANGE: footer for breaking changes.

Keep harness-added Co-Authored-By trailers — don't strip them.

Step 2 — Hygiene Check (flag before drafting)

Scan the staged diff for multiple unrelated concerns:

  • Different logical areas changed together (e.g., bug fix + dependency bump + formatting)?
  • Does describing the change require "and"?

If yes → flag it: "These look like separate logical changes — consider splitting into multiple commits." Then still draft the message for the combined change. The hygiene flag is advisory — do not block or wait for a response before producing the commit message.

When drafting a combined message: subject covers the most significant change; body lists the remaining changes with a one-line reason each.

Step 3 — Draft the Subject Line

  • Imperative mood: completes "If applied, this commit will ___"
    • ✓ Add null check for emailVerifiedAt in auth middleware
    • ✗ Added null check / Adding null check
  • 50 chars target, 72 hard limit — longer subjects get truncated in git log and GitHub
  • No trailing period
  • No vague words without concrete detail: avoid fix, update, change, improve, misc as the entire subject — always follow them with what specifically
    • ✓ Fix off-by-one error in pagination that skipped last item
    • ✗ Fix pagination bug
  • No "and" — if you need it, split the commit
  • No "This commit..." openers — in subject or body; describe the change directly

Step 4 — Write the Body (required for non-trivial changes)

The body answers the question: "Why did this change need to exist?"

For any change involving a decision, trade-off, or non-obvious fix, answer these:

  1. What was wrong before? What problem, gap, or constraint triggered this change?
  2. Why this approach? If alternatives existed, why this one?
  3. Who or what is affected? End users, CI, developers, a specific test, a downstream service? Make this the first sentence of the body when the scope is non-obvious — a CI-only fix in production code should open with "CI only — no user-facing behavior change" before explaining the mechanism.
  4. Anything the reader needs to know? Side effects, follow-ups, related issues?

The body is optional only for purely mechanical changes (version bumps, generated file updates, whitespace-only fixes).

The diff already shows what changed. Do not restate it.

# BAD — restates the diff
fix: add null check for emailVerifiedAt in auth middleware

Prevent null pointer by checking if emailVerifiedAt exists before
calling toISOString().

# GOOD — explains why it was a problem
fix: guard against null emailVerifiedAt crashing login flow

Unverified users have a null emailVerifiedAt. The auth middleware was
calling .toISOString() on it unconditionally, crashing the login
request with a TypeError. This only affects users who registered but
never confirmed their email.

Separate subject from body with a blank line. Wrap body lines at 72 chars.

Pre-Finalization Checklist

Before committing:

  • Subject matches the repo's convention (conventional commits type[scope]: description where the repo uses it, or by default)
  • Subject is imperative mood
  • Subject is ≤72 chars (≤50 preferred)
  • Subject has no trailing period
  • Subject has no vague words without concrete detail
  • Subject has no "and" (or hygiene flag was addressed)
  • Body is present for any non-trivial change
  • Body explains why, not what — could someone understand the reasoning without reading the diff?
  • Body lines wrap at 72 chars

Common Mistakes

MistakeFix
Body restates the diffAsk: "Does this say anything the diff doesn't?" If not, replace with why
Vague subject (fix bug, update files)Name the specific thing that changed and what happened to it
Combining unrelated changesFlag hygiene issue before drafting; suggest splitting
Writing body for a version bumpBody optional for mechanical changes with no decision involved
Burying the scope of impactState who/what is affected early — a CI-only fix in production code should not read like a user-facing bug fix

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.