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
- artivilla/agent-skillstheir own version, first seen Nov 8, 2026
- godot-fun/gaitheir own version, first seen Nov 1, 2026
- godot-fun/godot-agenttheir own version, first seen Nov 1, 2026
- cathaysia/skillstheir own version, first seen Oct 23, 2026
- shy-UCAS/claude-skillstheir own version, first seen Oct 20, 2026
- murongg/skillstheir own version, first seen Oct 20, 2026
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.
GoogleSkilltdd
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
Other versions22 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 22
- AkimioJR/AutoFilm★ 1.1ksame name
- overflow65537/MAA_Punish★ 384same name
- godot-fun/gai★ 202same name
- godot-fun/godot-agent★ 202same name
- 535803710/ai-rd-skills★ 8same name
- cathaysia/skills★ 2same name
- host452b/polish★ 2same name
- alapha888/agent-skills-en★ 1same name
- ankitgoyalio/skills★ 1same name
- bat-in-metropolis/git-commit-message-skill★ 1same name
12 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- architecture-decision-recordsSkill
- boy-scout-ruleSkill
- domain-driven-designSkill
- functional-core-imperative-shellSkill
- react-best-practicesSkill
- revise-for-claritySkill
- ux-design-principlesSkill
- ux-prototypingSkill
- ux-visual-evaluationSkill
- visual-feedback-loopSkill
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
- Very specific: line 24
Use standard types (feat, fix, docs, refactor, chore, test, style, perf, ci, build), an optional scope (feat(auth):), and a !
- Very specific: line 26
Keep harness-added Co-Authored-By trailers — don't strip them.
- Distinctive: line 35
If yes → flag it: *"These look like separate logical changes — consider splitting into multiple commits."* Then still draft the message for …
- Distinctive: line 37
When drafting a combined message: subject covers the most significant change.
- Distinctive: line 46
No vague words without concrete detail: avoid *fix, update, change, improve, misc* as the entire subject — always follow them with what …
- Distinctive: line 59
Why this approach?: If alternatives existed, why this one?
“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.
Files
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 logand 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:
- What was wrong before? What problem, gap, or constraint triggered this change?
- Why this approach? If alternatives existed, why this one?
- 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.
- 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]: descriptionwhere 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
| Mistake | Fix |
| Body restates the diff | Ask: "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 changes | Flag hygiene issue before drafting; suggest splitting |
| Writing body for a version bump | Body optional for mechanical changes with no decision involved |
| Burying the scope of impact | State who/what is affected early — a CI-only fix in production code should not read like a user-facing bug fix |
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
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.

