# Git Commit Message

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

- Skill: `alapha888/git-commit-message` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alapha888/git-commit-message`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alapha888/git-commit-message/raw
- Safety review: pending
- Works with: any agent that reads SKILL.md (Claude Code, Claude.ai, Cursor, Codex, Windsurf, 60+ more)
- Category: Docs & Writing
- License: MIT
- Author: alapha888 (https://skillmd.com/u/alapha888)
- Updated: 2026-10-04
- Page: https://skillmd.com/skills/alapha888/git-commit-message

---


# 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.

## 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."
```

## 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.