Git Commit Message Generator

Stop writing vague commit messages. Get perfectly formatted Conventional Commits from your staged changes in one command.

The Problem

You're staring at git diff --staged with 12 changed files across 3 modules. Writing a good commit message means understanding the full scope, picking the right type (feat vs fix vs refactor), scoping it correctly, and hitting the 50-character subject limit — all while your flow state drains away. The result: "WIP" commits, "fix stuff" messages, or "Updated files" nonsense that makes git bisect useless and your changelog a graveyard of "misc changes."

What You Get

• Automatic type detection — analyzes diff content to choose between feat, fix, docs, style, refactor, test, chore, perf, ci, build, and revert based on what files changed and what changed in them
• Scope inference — identifies the module, package, or domain affected (e.g., auth, api, payments) from file paths and import relationships
• Imperative mood subject line — generates "add OAuth2 login support" not "Added OAuth2 login support," respecting the 50-character limit
• Contextual body paragraphs — writes the "why" behind multi-file changes, design decisions, and cross-module impacts when the diff is complex enough to warrant explanation
• Breaking change detection — automatically identifies when a commit removes a public API, changes a function signature, or drops a config key, then formats the ! suffix and BREAKING CHANGE: footer
• Multiple-commit splitting suggestions — when a diff mixes unrelated changes (e.g., a feature + a refactor + a doc update), recommends splitting into focused, atomic commits

Why This Beats Prompting It Yourself

A prompt like "write me a commit message for this diff" produces messages that often use past tense ("Added," "Fixed"), skip the scope, omit breaking change footers, or describe the "what" instead of the "why." This skill encodes the full Conventional Commits specification — including the imperative-mood rule, the 50/72 character limits, the scope heuristics, and the BREAKING CHANGE: footer format — so every output is spec-compliant without manual correction.

Example Session

You: git diff --staged — 3 files changed: src/auth/oauth.py (new file, 45 lines), src/auth/middleware.py (modified, +8 -3), tests/test_auth.py (modified, +12 -1)

Agent:

feat(auth): add OAuth2 login support

Implement OAuth2 authorization code flow with PKCE for the login
middleware. The new OAuthHandler manages token exchange and refresh,
while the middleware validates Bearer tokens on protected routes.

Refs: #347

Use Cases

• Writing commit messages for multi-file PRs where the scope and type aren't obvious at a glance
• Enforcing Conventional Commits across a team by generating consistent messages as the default
• Detecting breaking changes in dependency upgrades or API modifications before they ship
• Auto-generating changelog-ready commits that flow directly into release notes
• Quickening the commit-flow when you're on a tight deadline and need clean history

Known Limitations

If your diff is a single line change, the generated message may feel verbose for the context. The skill works best on diffs touching 2+ files or making substantive logic changes — trivial formatting fixes may not benefit from a full Conventional Commit body.

Tags: git commits conventional-commits workflow developer-experience

Version: 1.0.0