agentleFS
anchildress1anchildress1/awesome-ai/skills/generate-commit-message/SKILL.md

generate-commit-message

Skill67 starsChanged 59 days agoMITView on GitHub

Derive one Conventional Commits v1.0.0 message from the staged diff and create the signed commit directly. Trigger only on explicit intent to commit: "commit this", "commit these changes", "/commit", "go ahead and commit", "make the commit", "git commit", or a confirmation like "yes, commit it". Enforces the type enum, 72-char subject, 100-char body/footer lines, and a required AI-attribution trailer, so the result passes commitlint on the first try. Do NOT trigger on message-only questions ("write a commit message", "what should the commit message be") — this skill's only output path is a real commit, and answering those with one records work the user merely asked to preview.

  • Commits and pushes

4 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

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Stop and report; do not work around:

    line 37
  2. Very specific:

    No staged diff → nothing staged.

    line 39
  3. Very specific:

    Never invent a keyword scope (core, api, docs) when no issue key exists.

    line 52
  4. Very specific:

    Match the repo before emitting: Read commitlint.config.js (or .commitlintrc*) if present and honor overrides — scope-case, stricter …

    line 136
  5. Distinctive:

    No line over its limit; exactly one attribution trailer present

    line 144

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Produce exactly one Conventional Commits v1.0.0 message from the diff, then commit it signed. The commit is the deliverable — no draft file, no staging, no push.

Boundaries

The only repo-mutating command permitted is git commit -S. Everything else is off-limits:

NeverWhy
git add / stage anythingCommit scope is the user's decision, already expressed by what's staged
git push, rebase, reset, commit --amendHistory mutation isn't this skill's job
--no-verify, --no-gpg-signHooks and signing must run
Edit source, docs, or configNo formatters, lint fixes, refactors, or test runs
Commit on main/masterUnless the user directed it this turn
Omit the AI-attribution trailerA message without it is a failed message

Abort conditions

Stop and report; do not work around:

  • No staged diff → nothing staged. Do not stage on the user's behalf.
  • On main/master without explicit authorization this turn.
  • Diff changed between derivation and commit (see step 5).

1. Resolve scope

Precedence, first match wins. Jira key regex [A-Z][A-Z0-9]+-\d+, matched case-insensitively, emitted uppercase:

  1. User-provided key (request or argument-hint)
  2. Branch name — git --no-pager rev-parse --abbrev-ref HEAD
  3. None — omit the scope

Never invent a keyword scope (core, api, docs) when no issue key exists. An absent scope is correct; a made-up one is noise. The diff informs type and subject, never scope.

2. Acquire diff

git --no-pager diff --cached

Empty → abort. There is no working-tree fallback: git commit records the index, so a message derived from unstaged edits would describe changes the commit doesn't contain — and the commit would fail anyway with nothing staged.

Derive everything from hunks only: chat history, prior commits, and memory are not evidence of what this diff changes.

3. Pick type

First match wins:

SignalType
Public API removed, signature changed, config key droppedbreaking — add ! and/or BREAKING CHANGE:
New user-visible capabilityfeat
Defect repair, no new surfacefix
Faster, same behaviorperf
Restructure, same behaviorrefactor
Whitespace, formatting, semicolonsstyle
Tests onlytest
Docs, comments, JSDoc/KDoc onlydocs
.github/workflows, .circleci, CI configci
Build system, deps, packagingbuild
Reverts a prior commitrevert
Maintenance, no production impactchore

4. Pick attribution tier

Exactly one, from diff hunks + this session:

AI share of the workTrailer
MajorityGenerated-by
Roughly halfCo-authored-by
Minor assistAssisted-by
Only wrote this messageCommit-generated-by

Uncertain → pick the tier that credits the human more.

Co-authored-by is the one tier GitHub actually parses and renders on the commit, which is the point of it — don't substitute a variant spelling. The other three are custom trailers that git carries verbatim.

5. Compose and validate

<type>[(<scope>)][!]: <subject>

- <single-line bullet>
- <single-line bullet>

<footers>

Format constraints — every one maps to a commitlint rule, so a violation is a hook failure, not a style opinion:

  • Subject ≤ 72 chars, no trailing period, imperative present tense. Not Title Case, sentence-case, PascalCase, or UPPER — but real identifiers keep their casing (OAuth2, JSDoc, API)
  • Type lowercase, from the enum in step 3
  • Body and footer lines ≤ 100 chars; bullets never wrap
  • Exactly one blank line after the subject, exactly one before the footers, none elsewhere
  • Group changes and say what and why. File-by-file listings and how are wasted lines. Quantify where it helps ("add 3 fixtures", "drop 412 LOC").

Footer order, when present:

  1. Refs: PROJ-123 / Closes #42
  2. BREAKING CHANGE: <incompatibility and required action> — only when the ! alone doesn't tell the user what to do. Both forms together are valid.
  3. AI attribution — required, exactly one, from step 4.

Trailers use - for spaces (Reviewed-by); BREAKING CHANGE is the spec's one exemption. A footer too long to fit in 100 chars folds onto a continuation line with a leading space.

Match the repo before emitting. Read commitlint.config.js (or .commitlintrc*) if present and honor overrides — scope-case, stricter lengths, a narrowed type enum. Then check git --no-pager log -3 for trailers this repo actually uses (Signed-off-by, Refs) and mirror them. A message that passes the generic spec but trips this repo's hook is still a failure.

Then verify before committing:

  • Header matches ^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\([^)]+\))?!?: .+$
  • No line over its limit; exactly one attribution trailer present

Failing any check → regenerate. Never emit a non-conformant message.

6. Re-check the diff

Re-run the step 2 command immediately before committing. If it changed, the message describes work that no longer matches — re-derive from step 2. If the diff can't be re-read, say the message may be stale and proceed.

7. Commit

git commit -S -F - <<'EOF'
<full message including blank lines and footers>
EOF

-F - preserves blank lines and trailers exactly; -m with embedded newlines is where formatting gets mangled. Report the short SHA and subject.

On failure — hook rejection, denied permission, signing error — do not retry blindly and do not amend. Print the composed message in a fenced block so the work isn't lost, surface the exact failure output, and state what the user likely needs to do. Then stop; the underlying problem is theirs to resolve, not something to work around.

Examples

fix: pin qs to 6.14.2 to address prototype-pollution vulnerability

- add npm override for qs across the dependency tree
- align instantsearch.js resolution to the pinned version

Assisted-by: Claude Haiku 4.5 <noreply@anthropic.com>
feat(PROJ-123): add OAuth2 device-code flow to login

- support polling the token endpoint with backoff
- surface user_code and verification_uri in CLI output
- cover happy-path and timeout in unit tests

Refs: PROJ-123
Generated-by: Claude Opus 5 <noreply@anthropic.com>
feat(PROJ-456)!: drop deprecated /v1 endpoints

- remove /v1/users and /v1/sessions handlers
- migrate fixture suite to /v2 equivalents

BREAKING CHANGE: clients pinned to /v1 must upgrade to /v2 before this release.
Generated-by: Claude Opus 5 <noreply@anthropic.com>

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.