version: "1.0.0" name: commit-message description: Generate a conventional git commit message from a description of changes. Use this skill whenever the user asks for a commit message, wants to write a commit, says things like "generate a commit", "write a commit message for", "what should my commit say", "help me commit this", or describes code changes and needs to capture them in version control. Even if the user just pastes a diff or says "I added X and fixed Y", offer a commit message.

Commit Message Generator

Generate clear, conventional git commit messages from a description of changes.

Format

Follow the Conventional Commits spec:

<type>(<optional scope>): <short description>
 
<optional body>
 
<optional footer>

Types:

• feat — new feature
• fix — bug fix
• refactor — code change that neither adds a feature nor fixes a bug
• chore — build process, tooling, dependency updates, non-functional
• docs — documentation only
• test — adding or updating tests
• perf — performance improvement
• style — formatting, whitespace (no logic change)
• ci — CI/CD pipeline changes

Rules:

• Subject line: max 72 characters, imperative mood ("add" not "adds" or "added"), no trailing period
• Scope: optional, lowercase, single word or hyphenated (e.g., auth, user-profile)
• Body: wrap at 72 chars, explain what and why (not how), blank line after subject
• Breaking changes: add BREAKING CHANGE: in footer, or ! after type (e.g., feat!:)

Process

1. Identify the dominant change type. If there are multiple changes, use the most impactful type (a feat that also fixes a bug is still feat).
2. Infer a scope from the files, modules, or component names if the user mentions them.
3. Write the subject in imperative mood — read it as "this commit will: <subject>".
4. Add a body only if the change needs context that isn't obvious from the subject alone.
5. Output the commit message in a code block so it's easy to copy.

If the user gives very little context, ask one clarifying question rather than guessing wildly (e.g., "Is this adding new behavior or fixing existing behavior?"). But if it's clear, just write it — don't over-ask.

Examples

Input: "I added a login page with email and password fields and wired it up to the auth API"

feat(auth): add login page with email/password form
 
Connects to the auth API for credential validation.

Input: "fixed the null pointer crash when user profile is missing"

fix(user-profile): handle missing profile to prevent null crash

Input: "updated lodash from 4.17.19 to 4.17.21"

chore(deps): upgrade lodash to 4.17.21

Input: "renamed getUserData to fetchUserProfile everywhere"

refactor(user): rename getUserData to fetchUserProfile