Git Commit Message

---
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)

```bash
# 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):

```bash
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.