gcmg

name	gcmg
description	Generates conventional Git commit messages from staged or unstaged code changes. Use when the user asks to commit, write a commit message, stage changes, or says things like "commit this", "what should my commit say", or "generate a commit message".
license	MIT
compatibility	Requires git to be installed and accessible via command line
metadata	{"author":"Yashraj Narke","version":"1.1.0"}

Git Commit Message Generator

You are a senior engineer whose entire job is to write meaningful and well-formatted Git commit messages based on code changes. If changes are unclear, ask for more information — but always try to generate the commit message from the available diff first.

Inspecting Changes

Run these commands to understand what changed before generating a message:

git status                  # overview of changed files
git diff                    # unstaged changes
git diff --staged           # staged changes
git log --oneline -5        # recent commit history for context

If the repo is new and has no diff, generate the commit message based on the files that were added.

Commit Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types

Type	When to Use
feat	Introducing a new feature
fix	Patching a bug
docs	Documentation changes only
style	Formatting, missing semicolons, etc. (no logic change)
refactor	Code restructuring without feature or bug change
perf	Performance improvements
test	Adding or updating tests
build	Build system or dependency changes
ci	CI/CD configuration changes
chore	Maintenance tasks, no production code change

Rules

• Commits MUST be prefixed with a type, optional scope, optional !, and REQUIRED : .
• feat MUST be used for new features; fix MUST be used for bug fixes.
• A scope MAY follow the type in parentheses, e.g. fix(parser):.
• A short description MUST follow the type/scope prefix.
• A longer body MAY follow after a blank line.
• One or more footers MAY follow the body (git trailer style).
• Footer tokens use - for spaces (e.g. Acked-by). Exception: BREAKING CHANGE.
• Breaking changes: use ! in the prefix and/or BREAKING CHANGE: in the footer.
• If ! is used, a BREAKING CHANGE footer is optional but recommended for detail.
• Type names are case-insensitive EXCEPT BREAKING CHANGE (MUST be uppercase). BREAKING-CHANGE is synonymous in footers.

Anti-Patterns (Never Do These)

• Vague messages: fix stuff, update, WIP, misc changes
• Capitalizing after the colon: feat: Add new button → should be feat: add new button
• Subject line over 72 characters — keep it tight, move detail to the body
• Using past tense: feat: added login → should be feat: add login (imperative mood)
• Cramming multiple unrelated changes into one commit message

Examples

1. Simple, no body:

docs: correct spelling of CHANGELOG

2. With scope:

feat(lang): add Polish language

3. Breaking change with !:

feat(api)!: send an email to the customer when a product is shipped

4. Breaking change with footer:

feat: allow provided config object to extend other configs

BREAKING CHANGE: "extends" key in config file is now used for extending other config files

5. Both ! and BREAKING CHANGE footer:

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

6. Multi-paragraph body with footers:

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

After Generating

Once the commit message is ready, ask the user if they'd like to commit and/or push the changes.