Git Commit Message Generation

Git Commit Message Generation reads actual staged changes and turns them into a commit message that explains what changed and why. The subject serves readers scanning history, while the optional body preserves the reason behind the change. Its output is a ready-to-run command rather than separate pieces of text that the user has to assemble.

The workflow begins with the repository status and the staged diff statistics. Those checks establish whether anything is staged before the skill writes a message. An empty staging area stops the workflow and prompts a question; it is not a reason to guess what a future commit might contain. The skill relies on the staged diff for evidence and asks for missing intent when the reason for a change cannot be inferred.

Use it to write, generate or polish a Git commit message, especially when staged changes need a conventional-commit subject and a body focused on why. It should not produce a message without staged changes. If one proposed commit combines different types of change, such as a feature and a refactor, the workflow asks for the changes to be split instead of concealing the distinction under one label.

Repository conventions take precedence over its defaults. A project that uses Gitmoji, Jira prefixes or another local convention can override the usual subject style. The skill writes the message only: decisions about staging, splitting, committing and pushing remain with the user. It never runs the commit command itself.

The primary input is the staged diff. The message uses exactly one type: feat for a new feature, fix for a bug fix, docs for documentation, refactor for behavior-preserving changes, test for tests, or chore for build work, dependencies and miscellaneous changes. It avoids treating every feature or fix as a catch-all chore.

The default subject follows a type prefix with an English imperative phrase of at most 50 characters. It starts with an action verb and avoids empty descriptions such as update code or some changes. The body, when supplied, uses one to three lines to explain the reason rather than narrating edits line by line. A bug fix states its trigger conditions; a feature describes the user-visible change. Generated and vendored files, including lockfiles and minified output, are summarized collectively.

A source example illustrates the command format and trigger-focused bug-fix body:

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

The message stays about the change. It excludes generation commentary and keeps implementation detail out of the subject when that detail belongs in the diff or the explanation of why.