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, git diff --cached --stat, and git diff --cached to confirm there is something staged. If staging is empty, use an explicitly supplied diff or change description when available and label that evidence; otherwise request the intended changes. Do not stage files implicitly.
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: return the message in the format requested. If supplying a shell command, quote it safely: commit text containing $(), backticks, or quotes must not execute as shell code. For a multiline message prefer writing it verbatim to a temporary file and using git commit -F <message-file>.

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.