---

name: git-commit-message description: "Generates conventional-commit messages from staged changes: type prefix + English imperative subject (≤50 chars) + optional body explaining why. Use when the user asks to write, generate, or polish a git commit message." category: development risk: safe source: https://github.com/alapha888/agent-skills-en source_repo: alapha888/agent-skills-en source_type: community date_added: "2026-10-01" author: alapha888 tags: [git, commit-messages, conventional-commits] tools: [claude, cursor, gemini, codex] license: MIT license_source: https://github.com/alapha888/agent-skills-en/blob/main/LICENSE

Git Commit Message Generation

Generate a commit message from the actual staged changes (git diff --cached). The message must let a reader know "what changed and why" without opening the diff.

When to Use

• Use when the user asks to write, generate, or polish a git commit message.
• Use when staged changes need a conventional-commit message with a why-focused body.

Workflow

1. Look at the changes: run git status --short and git diff --cached --stat to confirm there is something staged. If the staging area is empty, stop and ask the user — never invent a commit message out of nothing.
2. Pick a type: choose exactly one type prefix based on the changes (if one commit mixes types, ask the user to split it):
   • feat: new feature
   • fix: bug fix
   • docs: documentation only
   • refactor: refactor (behavior unchanged)
   • test: add or change tests
   • chore: build, dependencies, misc
3. Write the subject: format type: English imperative phrase, ≤50 characters. Start with a verb: "Add…", "Fix…", "Remove…", "Unify…". Ban empty subjects like "update code", "some changes", "fix bug".
4. Write the body (optional but recommended): 1–3 lines explaining why, not a play-by-play of how. Bug fixes must state the trigger conditions; features should describe the user-visible change.
5. Output: give a ready-to-run command, not bare text the user has to assemble.

Rules

• The subject is for skimmers; the body is for future-you in three months. Keep the two jobs separate.
• A change mixing a feature and a refactor should become two commits, not one feat that papers over the mess.
• No meta-commentary in the message ("generated by AI", etc.) — the message is about the change, nothing else.

Minimal example (runnable)

# 1. Look at the changes first
git status --short
git diff --cached --stat

# 2. Suppose the change: added CAPTCHA verification to the login endpoint
# Generated commit:
git commit -m "feat: add CAPTCHA verification to login endpoint" -m "Blocks automated credential stuffing; CAPTCHA valid 5 minutes, account locks 10 minutes after 3 failures."

Another example (bug fixes must state trigger conditions):

git commit -m "fix: keep order-list filters across pagination" -m "Trigger: filter first, then turn the page. Cause: page turns dropped the query params."

Limitations

• Only writes the message. Staging, splitting, committing and pushing remain the user's decision, and the skill never runs git commit on its own.
• The 50-character subject and imperative-mood conventions are the common default; repositories with their own commit convention (Gitmoji, Jira prefixes, project overrides) take precedence over this skill.
• It reads the staged diff, so it cannot describe intent that the diff alone does not show. When the "why" is not inferable, the skill asks instead of inventing it.
• Generated or vendored changes (lockfiles, minified output) are summarized collectively rather than listed line by line.

Anti-patterns

• ❌ Writing a message for an empty staging area: no git diff --cached, no commit message.
• ❌ Catch-all chore: labeling every feat and fix as chore until the type system means nothing.
• ❌ Novel-length subjects: feat: add a really useful feature that greatly improves the user experience — the subject says what, leave praise to the user.
• ❌ Body as implementation log: "first changed line 20 of a.py, then b.py…" — the diff already shows that; the body explains why.